[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guix --container is RAM hungry
From: |
Ludovic Courtès |
Subject: |
Re: guix --container is RAM hungry |
Date: |
Fri, 29 Mar 2024 00:30:57 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi Edouard,
Edouard Klein <edou@rdklein.fr> skribis:
> I'm a huge fan of guix --container, and I created a system to use those
> by default for network services. But the VPS these services run on has
> only 2GB of RAM, and I just realized that a container, by default,
> requires at least 200MB.
Ouch, confirmed:
--8<---------------cut here---------------start------------->8---
$ \time -v guix shell -C coreutils -- uname 2>&1 |grep 'Maximum resident'
Maximum resident set size (kbytes): 283048
$ \time -v guix shell coreutils -- uname 2>&1 |grep 'Maximum resident'
Maximum resident set size (kbytes): 56588
$ guix describe
Generation 297 Mar 24 2024 23:12:25 (current)
guix 28bc0e8
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 28bc0e870b4d48b8e3e773382bb0e999df2e3611
--8<---------------cut here---------------end--------------->8---
As raingloom and Ricardo wrote, there’s a Guile process that keeps
waiting.
The ‘-C’ variant has to load more modules and do more work (compute
derivations), so it’s not surprising that it takes more memory than the
other variant (on a cache hit it has nothing to do).
Merely loading (guix scripts shell) consumes a lot, but GC says it’s
“only” using 7 MiB out of this:
--8<---------------cut here---------------start------------->8---
$ \time -f %M guile -c '(use-modules (guix scripts shell)) (pk (quotient
(assoc-ref (gc-stats) (quote heap-size)) 1024))'
;;; (7204)
38272
--8<---------------cut here---------------end--------------->8---
So what we’re seeing here is probably the mappings made by the loader
(libguile/loader.c).
Needs more investigation…
Ludo’.