Pixi eats all my memory and then dies

[flying-sheep]

Checks

• I have checked that this issue has not already been reported.

• I have confirmed this bug exists on the latest version of pixi, using pixi --version.

Reproducible example

git clone https://github.com/holoviz/holoviews.git
git checkout 1f534a1b777bd87a8dc3ddbf299a7cae44159540
pixi install

it gets further than that, but it’s always a race against time to be able to copy it:

⠚ updating lock-file   [00:00:03] [━━━━━━━─────────────────────────────────]   14/82                                                                                                                                                                                                                      
  ⠉ test-311:linux-64    [00:00:03] resolving conda
  ⠉ test-311:win-64      [00:00:03] resolving conda
  ⠉ test-311:osx-64      [00:00:03] resolving conda
  ⠉ test-312:linux-64    [00:00:03] resolving conda
  ⠉ test-312:win-64      [00:00:03] resolving conda
  ⠉ test-ui:linux-64     [00:00:03] resolving conda
  ⠉ test-312:osx-64      [00:00:03] resolving conda
  ⠉ test-ui:osx-64       [00:00:03] resolving conda
  ⠉ test-ui:win-64       [00:00:03] resolving conda
  ⠉ test-gpu:linux-64    [00:00:03] resolving conda
  ⠉ test-core:linux-64   [00:00:03] resolving conda
  ⠤ default:linux-64     [00:00:01] resolving conda
  ⠲ default:win-64       [00:00:00] resolving conda
  ⠲ default:osx-64       [00:00:00] resolving conda
  ⠚ build:linux-64       [00:00:00] loading repodata
  ⠙ build:osx-64         [00:00:00] loading repodata                                                                                                                                                                                                                                                      

Issue description

I have 16GB of memory, and pixi doesn’t seem to have a setting to reduce the number of threads/processes it uses.

I’m pretty sure the OOM killer kills it.

Expected behavior

not that.

[ruben-arts]

Thanks for reporting!

[flying-sheep]

No problem! Some more details:

• I’m on Arch Linux
• I did witness the memory climbing until it almost filled up, so the OOM killer hypothesis is is a very informed guess

[AvishekMondalQC]

Implementing a memory limit as suggested here #2214 (comment) would be super helpful!

[ruben-arts]

I discussed that with @baszalmstra the other day but it doesn't seem like a memory limit is something we can technically do. But we do need to find a solution for this. Turning off/limiting concurrency should be doable.

[bollwyvl]

On the main, having robust parallelism for "things pixi does" (be they project-defined tasks, or "system" things that impact the graph like locking and installing envs) is a big limitation. Always needing a make-like -j, but only for solves, would be unsatisfying, as installing envs in parallel, running tests in parallel, or starting multiple long-running processes would all benefit from some resource-aware scheduling.

[MarcSkovMadsen]

+1. I experience the same issues. See panel-extensions/copier-template-panel-extension#4 (comment).

[baszalmstra]

I investigated this further and confirm that the solver is using a lot of memory due to a very high number of possible candidates for some packages. Specifically pyarrow and arrow-cpp.

We will fix this in the solver but its a relatively large refactor that will take some time.

[ruben-arts]

In #2569 we implemented an escape hatch so you can define a max set of --concurrent-solves so you can tell pixi to stress the system less.

[ruben-arts]

As an update, huge improvements are on it's way. @baszalmstra had some fun over Christmas:

• perf: reintroduce binary encoding of forbid clauses resolvo#91
• refactor: reduce watchmap memory size resolvo#92

[ruben-arts]

We're currently not actively searching for more solutions to this problem. If you encounter this, please share the environment and on what machine you are running this.

[flying-sheep]

OK, this seems good now!