opam uses too much memory and gets killed

[Perdu]

I'm trying to install packages on Arch Linux on a machine with 1 GB of RAM (Raspberry Pi 3B). However, any action takes a lot of RAM and gets killed:

$ opam install -y curses
Processus stopped

$ opam install -y hevea
Processus stopped

$ opam pin curses 1.0.10
[NOTE] Pinning unchanged
curses is now pinned to version 1.0.10

Processus stopped

Is 1 GB memory not sufficient to run opam? Am I missing something?

There are other bug reports mentioning memory issues, but they should be fixed with the version I use.

# opam config report
# opam-version         2.1.2 
# self-upgrade         no
# system               arch=arm64 os=linux os-distribution=archarm os-version=unknown
# solver               builtin-mccs+glpk
# install-criteria     -removed,-count[avoid-version,changed],-count[version-lag,request],-count[version-lag,changed],-count[missing-depexts,changed],-changed
# upgrade-criteria     -removed,-count[avoid-version,changed],-count[version-lag,solution],-count[missing-depexts,changed],-new
# jobs                 3
# repositories         1 (http) (default repo at c84da638)
# pinned               1 (version)
# current-switch       default
# ocaml:native         true
# ocaml:native-tools   true
# ocaml:native-dynlink true
# ocaml:stubsdir       /usr/lib/ocaml/stublibs:/usr/lib/ocaml
# ocaml:preinstalled   true
# ocaml:compiler       system
# ocaml-system:path    /bin

[kit-ty-kate]

Is 1 GB memory not sufficient to run opam?

It’s possible. It’s taking 384MB of memory on my machine (arm64 as well), so depending on what else is running on your machine it may be insufficiant.

Do you have /tmp mounted as tmpfs by any chance? If so #5015 should be able to fix that (if you have ~400MB of free memory)

[kit-ty-kate]

I had a shot at memtrace’ing it and here is the quick result:

• 100MB was taken by the repository state (which can’t be reduced I’m afraid)
• 122MB was taken by the dose3 solver
  • that one we can be removed
  • it was introduced in Check for a solution before calling the solver #4263 as part of opam 2.1.0
  • I tested with opam option solver=builtin-0install on master (Make the SAT preemptive check optional, by-solver #4880) and it was only taking 288MB
• the rest of the bulk of memory is taken by the cudf conversion step, but there was too many small allocations to keep track of and have an easy scapegoat.

So to summarize this seems to be a regression from opam 2.0 brought by #4263

I’m slowly working towards eliminating dose to replace it by the 0install-solver so hopefully this will get fixed in all cases (even with #4880, dose is at least used in case of conflicts) in opam 2.2.0 but I can’t promesse I will have the time to do this specific thing as it is quite intricatly linked with opam in its current state.