From 6d4e0e5fa12c5108bed00e81c9d54a7f1c96688e Mon Sep 17 00:00:00 2001 From: atlas Date: Mon, 7 Sep 2026 16:48:10 +0200 Subject: [PATCH] docs/ci: say to measure the GC window before relying on the stagger MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The guidance says to stagger two hosts' collections, and never says how long one takes — so an operator picking `dates` has no way to know whether their stagger is wide enough. The number that matters is theirs, not mine: a collection's wall clock is dominated by the sweep over unused `.links` entries, which scales with the size of the store rather than with what the run deletes. So a store's size, not its churn, decides the window, and `randomizedDelaySec` spreads only the start. Measured here for scale, and deliberately kept out of the doc since it does not transfer: 11 runs over two weeks ranged 5min 16s to 51min 25s, inversely — the 51-minute run deleted 732 paths, a 12-minute run deleted 21,901. Refs #4019. --- docs/scheduler/ci.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/docs/scheduler/ci.md b/docs/scheduler/ci.md index af9df2c5..b5883a9a 100644 --- a/docs/scheduler/ci.md +++ b/docs/scheduler/ci.md @@ -234,6 +234,13 @@ following to your host config: } ``` +**Measure a collection on your own hosts before relying on that stagger.** +`randomizedDelaySec` spreads the _start_, not the run, and the run is dominated +by the sweep over unused `.links` entries — which scales with the size of the +store, not with what this collection deletes. On a large store it can take most +of an hour, so two hosts both set to `daily` may overlap however much jitter you +give them. `journalctl -u nix-gc.service` reports each run's wall clock. + **Remote builders:** if CI dispatches builds to a remote builder (for example via `nix.buildMachines` / `ssh-ng://`), the build outputs land in _that host's_ store, so the same GC config should be applied wherever the builder runs —