From: Ricardo Wurmus <rekado@elephly.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: 24937@debbugs.gnu.org
Subject: bug#24937: "deleting unused links" GC phase is too slow
Date: Thu, 16 Apr 2020 15:26:58 +0200 [thread overview]
Message-ID: <87ftd3muhp.fsf@elephly.net> (raw)
In-Reply-To: <87vaunbvcu.fsf@mdc-berlin.de>
Ricardo Wurmus <ricardo.wurmus@mdc-berlin.de> writes:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Ricardo, Roel: would you be able to run that links-traversal.c from
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?filename=links-traversal.c;bug=24937;msg=25;att=1>
>> on a machine with a big store, as described at
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24937#25>?
>
> I just ran this on my workstation in the office where I regularly build
> packages. Here’s the output of “df -i /gnu”
>
> Filesystem Inodes IUsed IFree IUse% Mounted on
> /dev/mapper/fedora-root 3301376 1098852 2202524 34% /
>
> Probably not large enough to derive conclusions about hydra’s behaviour.
>
> [I can’t run it on the shared store at the MDC because NFS performance is
> too poor. I recently ran “guix gc --optimize” to dedupe the shared
> store (post-build deduplication is disabled since a few weeks) and it’s
> at 3,197,489 used inodes.]
>
> Here are the results of running the link-traversal code on my
> workstation:
>
> --8<---------------cut here---------------start------------->8---
> rwurmus in ~: gcc -std=gnu99 -Wall links-traversal.c -DMODE=3
> rwurmus in ~: sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> rwurmus in ~: time ./a.out
> 412825 dir_entries, 107 seconds
> stat took 0 seconds
>
> real 1m47.264s
> user 0m0.214s
> sys 0m1.314s
>
> rwurmus in ~: gcc -std=gnu99 -Wall links-traversal.c -DMODE=2
> rwurmus in ~: sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'
> rwurmus in ~: time ./a.out
> 12821 dir_entries, 107 seconds (including stat)
>
> real 1m46.475s
> user 0m0.201s
> sys 0m1.309s
> --8<---------------cut here---------------end--------------->8---
I ran this for the first time on ci.guix.gnu.org, which has a very big
store (currently at around 29TB).
df -i /gnu:
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/sdb1 610021376 132350406 477670970 22% /gnu
I had to increase the number of MAX_ENTRIES to 135000000.
I forgot to drop caches initially. This is the first run:
--8<---------------cut here---------------start------------->8---
root@berlin ~ [env]# gcc links-traversal.c -DMODE=3 -o links-traversal
root@berlin ~ [env]# time ./links-traversal
57079502 dir_entries, 3906 seconds
stat took 136 seconds
real 67m48.145s
user 0m59.575s
sys 2m30.065s
--8<---------------cut here---------------end--------------->8---
I aborted the run after I dropped caches after 67 minutes.
I’m going to continue testing on one of the build nodes, and I’ll try
using statx.
--
Ricardo
next prev parent reply other threads:[~2020-04-16 13:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-11-13 17:41 bug#24937: "deleting unused links" GC phase is too slow Ludovic Courtès
2016-12-09 22:43 ` Ludovic Courtès
2016-12-11 13:46 ` Ludovic Courtès
2016-12-11 14:23 ` Mark H Weaver
2016-12-11 18:02 ` Ludovic Courtès
2016-12-11 19:27 ` Mark H Weaver
2016-12-13 0:00 ` Ludovic Courtès
2016-12-13 12:48 ` Mark H Weaver
2016-12-13 17:02 ` Ludovic Courtès
2016-12-13 17:18 ` Ricardo Wurmus
2020-04-16 13:26 ` Ricardo Wurmus [this message]
2020-04-16 14:27 ` Ricardo Wurmus
2020-04-17 8:16 ` Ludovic Courtès
2020-04-17 8:28 ` Ricardo Wurmus
2016-12-13 4:09 ` Mark H Weaver
2016-12-15 1:19 ` Mark H Weaver
2021-11-09 14:44 ` Ludovic Courtès
2021-11-09 15:00 ` Ludovic Courtès
2021-11-11 20:59 ` Maxim Cournoyer
2021-11-13 16:56 ` Ludovic Courtès
2021-11-13 21:37 ` bug#24937: [PATCH 1/2] tests: Factorize 'file=?' Ludovic Courtès
2021-11-13 21:37 ` bug#24937: [PATCH 2/2] daemon: Do not deduplicate files smaller than 4 KiB Ludovic Courtès
2021-11-16 13:54 ` bug#24937: "deleting unused links" GC phase is too slow Ludovic Courtès
2021-11-13 21:45 ` Ludovic Courtès
2021-11-22 2:30 ` John Kehayias via Bug reports for GNU Guix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87ftd3muhp.fsf@elephly.net \
--to=rekado@elephly.net \
--cc=24937@debbugs.gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.