GNU bug report logs - #38167
guix pull takes over 8 GiB of memory to finish if there are no substitutes

Previous Next

Package: guix;

Reported by: Danny Milosavljevic <dannym <at> scratchpost.org>

Date: Mon, 11 Nov 2019 07:08:02 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #29 received at 38167 <at> debbugs.gnu.org (full text, mbox):

From: Danny Milosavljevic <dannym <at> scratchpost.org>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 38167 <at> debbugs.gnu.org
Subject: Re: bug#38167: guix pull takes over 8 GiB of memory to finish if
 there are no substitutes
Date: Sat, 28 Dec 2019 12:01:28 +0100
[Message part 1 (text/plain, inline)]
Hi Ludo,

On Fri, 27 Dec 2019 19:11:08 +0100
Ludovic Courtès <ludo <at> gnu.org> wrote:

> Danny Milosavljevic <dannym <at> scratchpost.org> skribis:
> 
> > USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
> > dannym   19221 20.8 87.4 9404812 6884184 pts/0 Tl   20:34   2:40 /gnu/store/sc7z07gim1iq5zvfz1amdwf2irxrzifg-guile-2.2.6/bin/guile --no-auto-compile /home/dannym/.config/guix/current/bin/guix pull  
> 
> Oh, that’s an RSS of 6 GiB for ‘guix pull’ itself?  Weird, I don’t see
> how that can happen.
> 
> Could it be that ~/.cache/guix/checkouts/THE-THING is too big, which in
> turn causes libgit2 to consume too much memory somehow?

$ du -hs ~/.cache/guix/checkouts/
395M    /home/dannym/.cache/guix/checkouts/

> What happens if you attach strace to this process at the moment where
> it’s consuming a lot of memory?  Is it traversing Git pack files or
> something like that?

Right now the process is in a paused state and I think when I attach strace
it will continue.  Should I still do it?  I don't want to destroy our debugging
opportunity.

I could also attach gdb--I think that won't resume.
[Message part 2 (application/pgp-signature, inline)]

This bug report was last modified 4 years and 228 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.