‘guix publish’ memory leak

  • Done
  • quality assurance status badge
Details
One participant
  • Ludovic Courtès
Owner
unassigned
Submitted by
Ludovic Courtès
Severity
important
L
L
Ludovic Courtès wrote on 6 Mar 22:39 +0100
‘guix publish’ memory leak
(address . bug-guix@gnu.org)
87zfvb6nwi.fsf@inria.fr
It seems that ‘guix publish’ has been leaking memory noticeably I’d say
since the beginning of the year on berlin. After roughly 10 days, it
has several GiB resident and needs to be restarted or it becomes too
unresponsive.

I wonder what could be causing this because we used to let it run for
months without problems I believe.

This is what’s currently running on berlin:

/gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/libexec/guix/guile \
/gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/bin/guix \
publish -u guix-publish -p 3000 -C lzip:9 -C zstd:19 --nar-path=nar \
--listen=localhost --workers=8 --ttl=15552000s \
--cache=/var/cache/guix/publish --cache-bypass-threshold=157286400

… coming from commit 21e4d6cd6913eca131f2c0fd0cd509fc843c7eb8.

I don’t see anything that changed recently, be it in maintenance.git
(for the parameters), ‘guix publish’, guile-{lzlib,zstd}, or Guile.
Maybe we had just been lucky? Anyone else seeing this?

Ludo’.
L
L
Ludovic Courtès wrote on 4 Apr 23:20 +0200
control message for bug #69596
(address . control@debbugs.gnu.org)
87il0wu8ol.fsf@gnu.org
severity 69596 important
quit
L
L
Ludovic Courtès wrote 22 hours ago
Re: bug#69596: ‘guix publish’ memory leak
(address . 69596@debbugs.gnu.org)
87le4xgn5n.fsf@gnu.org
Hi!

Ludovic Courtès <ludo@gnu.org> skribis:

Toggle quote (18 lines)
> It seems that ‘guix publish’ has been leaking memory noticeably I’d say
> since the beginning of the year on berlin. After roughly 10 days, it
> has several GiB resident and needs to be restarted or it becomes too
> unresponsive.
>
> I wonder what could be causing this because we used to let it run for
> months without problems I believe.
>
> This is what’s currently running on berlin:
>
> /gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/libexec/guix/guile \
> /gnu/store/cpnshv80n3mar5lwp4qqa2dxxxv4zb03-guix-1.4.0-16.aeb4943/bin/guix \
> publish -u guix-publish -p 3000 -C lzip:9 -C zstd:19 --nar-path=nar \
> --listen=localhost --workers=8 --ttl=15552000s \
> --cache=/var/cache/guix/publish --cache-bypass-threshold=157286400
>
> … coming from commit 21e4d6cd6913eca131f2c0fd0cd509fc843c7eb8.

It turned out to be a guile-lzlib leak that had always been present:


The reason we were seeing it more on berlin is probably because we
increased the cache-bypass-threshold, which goes through the
‘make-lzip-output-port’ code path (as opposed to
‘call-with-lzip-output-port’).

The bug could be reproduced with:

guix publish -p 8124 … &
while true ; do wget -q -O/dev/full http://localhost:8124/nar/lzip/…-coreutils-9.1; done

(Replace the ellipses with the actual store file name of coreutils.)

Fixed by commit 7cef6b7ba555a9dfaf6d09cb7e112b0df77d5141, which updates
guile-lzlib.

Ludo’.
L
L
Ludovic Courtès wrote 22 hours ago
control message for bug #69596
(address . control@debbugs.gnu.org)
87jzkhgn5b.fsf@gnu.org
close 69596
quit
?