Maxim Cournoyer <maxim.courno...@gmail.com> writes:
> Hi Ludovic, > > Ludovic Courtès <l...@gnu.org> writes: > >> Hi Edouard, >> >> Edouard Klein <e...@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: >> >> $ \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 >> >> >> As raingloom and Ricardo wrote, there’s a Guile process that keeps >> waiting. > > Is there a technical reason for this? Couldn't we replace the > current Guix process with 'exec', as hinted by Edouard? > Raingloom did, I just reported the problem without investigating the cause. > > If possible, that'd be the most direct way to avoid any of the memory > cost incurred by Guile/Guix. I stand ready to test any WIP patch, I'll take a look as well to see if I can guess where to replace a fork with an exec. Ricardo's breakdown of the calls will be helpful. Thank you all for having taken the report into account.