| Message ID | 40bd5a0087d54531aabe2d0ce8d0cd2a6bd7e547.1717487258.git.ludo@gnu.org |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#71357] substitute: Don’t keep cache entries more than a few days. | expand |
This looks good! Andreas
Ludovic Courtès <ludo@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.
Hi, Christopher Baines <mail@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’.
Ludovic Courtès <ludo@gnu.org> skribis: > Thanks, pushed as 7e00fb9f31f51ac2f9fa67b71a3eb8aaa23efdb6. I’ll update > the ‘guix’ package soonish. Done in bd5c61781c13611ed16686513980907c6ee34ae6.
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 ()