[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guix --container is RAM hungry
From: |
Edouard Klein |
Subject: |
Re: guix --container is RAM hungry |
Date: |
Tue, 02 Apr 2024 22:33:18 +0200 |
User-agent: |
mu4e 1.10.2; emacs 28.2 |
Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
> Hi Ludovic,
>
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> 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:
>>
>> $ \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.
- Re: guix --container is RAM hungry,
Edouard Klein <=