From c95f9fe5dc05efd0cc1241217eacf001df59c45e Mon Sep 17 00:00:00 2001 From: zzstoatzz Date: Thu, 30 Jul 2026 06:40:32 -0500 Subject: [PATCH] docs: bloom oversizing also costs ~10% of wall time in repeated startup manifest.zig keeps sealed-segment metadata resident, so the 39.5 GiB of oversized per-block blooms must be loaded before backfill can start. Measured startup latency (process start -> "starting repository backfill") across experiment 6: early in the run: 2.0 min median by hour 54: 4.5 min median (last 10 restarts) It doubled as the archive grew, which is what you would expect if the cost tracks resident bloom bytes rather than anything fixed. The process restarts about every 45 minutes at the batch boundary, so this is roughly 10% of wall-clock time in startup and climbing -- about 1.8h of the 17.6h of crawl still remaining. Same root cause as the memory ceiling already recorded here, so right-sizing the blooms should shrink the resident footprint and this recurring startup tax together. Co-Authored-By: Claude Opus 5 (1M context) --- docs/jss-seal-spec.md | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/docs/jss-seal-spec.md b/docs/jss-seal-spec.md index 78b5b8a..ba7c947 100644 --- a/docs/jss-seal-spec.md +++ b/docs/jss-seal-spec.md @@ -41,6 +41,22 @@ file describes how to *write* it. > correctness: an oversized bloom still has no false negatives, so nothing > served is wrong. It is the reason the workload needs a 61 GB machine and the > likely reason it was OOM-killed once at 62.9 GB anon-rss. +> +> **It is also paid a second time, on every startup.** `manifest.zig` holds +> resident sealed-segment metadata, so those 39.5 GiB have to be loaded before +> backfill can begin. Measured latency from process start to +> `starting repository backfill` across experiment 6's restarts: +> +> | | | +> |---|---| +> | early in the run (median) | 2.0 min | +> | by hour 54 (median of last 10) | **4.5 min** | +> +> It doubled as the archive grew, which is the shape you would expect if the +> cost tracks resident bloom bytes rather than anything fixed. With the process +> restarting roughly every 45 minutes at the batch boundary, that is **~10% of +> wall-clock time spent in startup**, and rising. Right-sizing the blooms should +> shrink both the resident footprint and this recurring startup tax together. ## if you are reading this cold -- 2.51.2