GNU bug report logs - #71357
[PATCH] substitute: Don’t keep cache entries more than a few days.

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 71357 in the body.
You can then email your comments to 71357 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: guix-patches <at> gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>
Subject: [PATCH] substitute: Don’t keep cache entries more than a few days.
Date: Tue,  4 Jun 2024 10:06:43 +0200

Experience has shown that keeping too many entries increases disk usage
and, more importantly, leads to long delays when cleaning up the cache,
measured in minutes on slow or busy HDDs with hundreds of thousands of
cache entries, as is common on build machines.  In those cases, the cost
of the cache outweighs its benefit.

* guix/scripts/substitute.scm (%narinfo-expired-cache-entry-removal-delay):
Reduce to 5 days.
(cached-narinfo-expiration-time)[max-ttl]: Reduce to 2 days.

Change-Id: Iab212f572ee9041be61716423a3c014f93fe81ed
---
 guix/scripts/substitute.scm | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

Hello,

Chris mentioned it before and I experienced it the hard way on bayfront:

  https://lists.gnu.org/archive/html/guix-devel/2024-05/msg00177.html

A big narinfo cache is a significant performance hit on spinning HDDs
when the time comes to remove expired entries.

This change makes the cache more ephemeral (2 to 5 days).  I still think
some caching is needed: one will often run several Guix commands in a
day that will query the same narinfos and will only download/build a
small subset (keep in mind that that ‘substitution-oracle’, used by
‘derivation-build-plan’, query narinfos for the closure of the requested
derivations, minus those already valid); it would be wasteful and
inefficient to download them over and over again.  I’d like to have
metrics to estimate that, but I don’t.

Thoughts?

Ludo’.

diff --git a/guix/scripts/substitute.scm b/guix/scripts/substitute.scm
index a7ad56dbcd5..8bcbca5e7aa 100755
--- a/guix/scripts/substitute.scm
+++ b/guix/scripts/substitute.scm
@@ -77,7 +77,7 @@ (define-module (guix scripts substitute)
 
 (define %narinfo-expired-cache-entry-removal-delay
   ;; How often we want to remove files corresponding to expired cache entries.
-  (* 7 24 3600))
+  (* 5 24 3600))
 
 (define (warn-about-missing-authentication)
   (warning (G_ "authentication and authorization of substitutes \
@@ -169,8 +169,9 @@ (define (cached-narinfo-expiration-time file)
   "Return the expiration time for FILE, which is a cached narinfo."
   (define max-ttl
     ;; Upper bound on the TTL used to avoid keeping around cached narinfos for
-    ;; too long, which makes the cache bigger and more expensive to traverse.
-    (* 2 30 24 60 60))                            ;2 months
+    ;; too long, which makes the cache bigger and more expensive to traverse
+    ;; when deleting old entries.
+    (* 2 24 60 60))
 
   (catch 'system-error
     (lambda ()

base-commit: 85ac164c41fc4c93d3cb2a5d3321c63598c2855f
-- 
2.45.1

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

From: Andreas Enge <andreas <at> enge.fr>
To: 71357 <at> debbugs.gnu.org
Subject: Plus 1
Date: Mon, 10 Jun 2024 12:17:55 +0200

This looks good!

Andreas

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

From: Christopher Baines <mail <at> cbaines.net>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 71357 <at> debbugs.gnu.org, Josselin Poiret <dev <at> jpoiret.xyz>,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>, Ricardo Wurmus <rekado <at> elephly.net>,
 Christopher Baines <guix <at> cbaines.net>
Subject: Re: [bug#71357] [PATCH] substitute: Don’t keep
 cache entries more than a few days.
Date: Mon, 10 Jun 2024 12:57:48 +0100

[Message part 1 (text/plain, inline)]

Ludovic Courtès <ludo <at> gnu.org> writes:

> Experience has shown that keeping too many entries increases disk usage
> and, more importantly, leads to long delays when cleaning up the cache,
> measured in minutes on slow or busy HDDs with hundreds of thousands of
> cache entries, as is common on build machines.  In those cases, the cost
> of the cache outweighs its benefit.
>
> * guix/scripts/substitute.scm (%narinfo-expired-cache-entry-removal-delay):
> Reduce to 5 days.
> (cached-narinfo-expiration-time)[max-ttl]: Reduce to 2 days.
>
> Change-Id: Iab212f572ee9041be61716423a3c014f93fe81ed
> ---
>  guix/scripts/substitute.scm | 7 ++++---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> Hello,
>
> Chris mentioned it before and I experienced it the hard way on bayfront:
>
>   https://lists.gnu.org/archive/html/guix-devel/2024-05/msg00177.html
>
> A big narinfo cache is a significant performance hit on spinning HDDs
> when the time comes to remove expired entries.
>
> This change makes the cache more ephemeral (2 to 5 days).  I still think
> some caching is needed: one will often run several Guix commands in a
> day that will query the same narinfos and will only download/build a
> small subset (keep in mind that that ‘substitution-oracle’, used by
> ‘derivation-build-plan’, query narinfos for the closure of the requested
> derivations, minus those already valid); it would be wasteful and
> inefficient to download them over and over again.  I’d like to have
> metrics to estimate that, but I don’t.
>
> Thoughts?

This sounds good to me.

I think one of the problems on bayfront is that each substitute process
looks and decides it's time to remove the expired cache entries. For
every new process that starts and decides to join it, it probably slows
them all down. This is very similar to a "thundering herd" since the
processes trip over each other trying to delete the same files.

This change won't directly address that part of the issue, but maybe
keeping the cache smaller will help reduce the impact when this happens.

[signature.asc (application/pgp-signature, inline)]

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 71357 <at> debbugs.gnu.org, Josselin Poiret <dev <at> jpoiret.xyz>,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>, Ricardo Wurmus <rekado <at> elephly.net>,
 Andreas Enge <andreas <at> enge.fr>, Christopher Baines <guix <at> cbaines.net>
Subject: Re: [bug#71357] [PATCH] substitute: Don’t keep
 cache entries more than a few days.
Date: Thu, 13 Jun 2024 11:50:29 +0200

Hi,

Christopher Baines <mail <at> cbaines.net> skribis:

> This sounds good to me.

Thanks, pushed as 7e00fb9f31f51ac2f9fa67b71a3eb8aaa23efdb6.  I’ll update
the ‘guix’ package soonish.

> I think one of the problems on bayfront is that each substitute process
> looks and decides it's time to remove the expired cache entries. For
> every new process that starts and decides to join it, it probably slows
> them all down. This is very similar to a "thundering herd" since the
> processes trip over each other trying to delete the same files.

Oh right.  I’m not sure if this is what I was seeing, but it can
definitely be a problem on build machines.  We should change (guix
cache) to avoid that.

Thanks!

Ludo’.

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

From: Ludovic Courtès <ludo <at> gnu.org>
To: Christopher Baines <mail <at> cbaines.net>
Cc: 71357 <at> debbugs.gnu.org, Josselin Poiret <dev <at> jpoiret.xyz>,
 Simon Tournier <zimon.toutoune <at> gmail.com>, Mathieu Othacehe <othacehe <at> gnu.org>,
 Tobias Geerinckx-Rice <me <at> tobias.gr>, Ricardo Wurmus <rekado <at> elephly.net>,
 Andreas Enge <andreas <at> enge.fr>, Christopher Baines <guix <at> cbaines.net>
Subject: Re: [bug#71357] [PATCH] substitute: Don’t keep
 cache entries more than a few days.
Date: Sun, 16 Jun 2024 23:15:14 +0200

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

> Thanks, pushed as 7e00fb9f31f51ac2f9fa67b71a3eb8aaa23efdb6.  I’ll update
> the ‘guix’ package soonish.

Done in bd5c61781c13611ed16686513980907c6ee34ae6.

Previous Next

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