nix: use boehmgc with enableLargeConfig = true #43021
Conversation
|
TODO: check for this increasing memory consumption. (Thanks Eelco!) |
|
Success on x86_64-darwin (full log) Attempted: nix Partial log (click to expand)
|
|
Success on x86_64-linux (full log) Attempted: nix Partial log (click to expand)
|
|
Success on aarch64-linux (full log) Attempted: nix Partial log (click to expand)
|
|
Increased memory usage (as reported in #43015 (comment)) isn't necessarily a problem. Normal caveats of measuring memory usage of GC'd code apply-- boehmgc quite understandably is likely less aggressive about collecting at a given heap size when using the large config. While this could be tuned I'd suggest leaving it as-is and only worrying about what happens when memory is limited. Maybe run a number of large builds for varying maximum heap sizes and measure heap usage and total execution time? Might be a simpler way to investigate but that's at least easy to try :). |
|
Also-- I've tried this setting a number of times when investigating other instances where the MAX_HEAP_SECTS (or whatever :3) error is printed... but it never seemed to actually fix the problem I was encountering? I'm not super confident I'm remembering the details right (I can dig up my notes if that'd be useful), Thanks! |
|
I had tested this fixes the tarball job for me, of course. |
Fixes NixOS#43015 for me and hopefully also similar issues. == Resource consumption == TL;DR: no change for small-memory cases, less CPU for large-memory cases. I assume almost all of the large memory usage is just the expression evaluation and managed by the GC, so I used just `nix-env -q...` to test. Old and new lines for each command follow. I tried to run each several times, but the values were very stable (<1% difference on re-runs), so only one line for each command-version pair is provided. $ time nix-env -f . -qaP --description -A nix >/dev/null - 0.06user 0.01system 0:00.07elapsed 101%CPU (0avgtext+0avgdata 29036maxresident)k + 0.06user 0.01system 0:00.07elapsed 102%CPU (0avgtext+0avgdata 29864maxresident)k $ time nix-env -f . -qaP --description >/dev/null - 6.45user 0.36system 0:06.82elapsed 99%CPU (0avgtext+0avgdata 1021024maxresident)k + 6.23user 0.33system 0:06.57elapsed 100%CPU (0avgtext+0avgdata 938408maxresident)k $ time nix-env -f . --show-trace -qa --drv-path --system --meta --xml 2>&1 >/dev/null - 56.35user 0.96system 0:31.03elapsed 184%CPU (0avgtext+0avgdata 3207708maxresident)k + 44.80user 0.91system 0:26.12elapsed 175%CPU (0avgtext+0avgdata 3192696maxresident)k $ time ./result-nix-large/bin/nix-instantiate --dry-run --eval --strict \ --show-trace ./maintainers/scripts/eval-release.nix > /dev/null - Too many heap sections: Increase MAXHINCR or MAX_HEAP_SECTS - Command terminated by signal 6 - 175.18user 2.68system 1:17.42elapsed 229%CPU (0avgtext+0avgdata 8468440maxresident)k + 178.48user 2.78system 1:15.11elapsed 241%CPU (0avgtext+0avgdata 8460572maxresident)k
vcunat
force-pushed
the
p/nix-MAX_HEAP_SECTIONS
branch
from
b8d2e6e
to
1bdb138
Compare
|
I believe upstream docs indicate that we should use Performance measurements added to the commit message; TL;DR: no change for small-memory cases, less CPU for large-memory cases. |
|
Success on aarch64-linux (full log) Attempted: nix Partial log (click to expand)
|
|
Success on x86_64-darwin (full log) Attempted: nix Partial log (click to expand)
|
|
18.03 has had some tarball failures that look similar. Should we backport this? |
|
Success on x86_64-linux (full log) Attempted: nix Partial log (click to expand)
|
|
I haven't noticed that. If it happens, we might be more conservative there and only override nix used in the tarball job. |
|
I enabled this on Hydra, but it made no difference. |
From source-code comment I expect we should be fine with that setting:
/* overflows at roughly 128 GB */
Fixes #43015 and also similar issues, hopefully.