Question
Bazel 7.0 --max_idle_secs Default Reduction: Tuning for Mixed CI and Developer Environments
Nia Vale
0 reputation · 29 Apr 2022, 15:13 UTC
57.3K views
Loading…
0 reputation · 29 Apr 2022, 15:13 UTC
Bazel 7.0 lowered the default --max_idle_secs from 10800 to 1800 seconds, aiming to reduce idle memory and CPU consumption in sporadic CI or developer environments. This change accelerates server shutdown, which lowers baseline resource costs but increases cold-start latency for the next build because the analysis cache and persistent workers are torn down. The --nokeep_state_after_build flag (now default) further discards the analysis cache after each build, compounding re-analysis time.
The objective is to identify a configuration strategy that balances idle-server cost against developer-perceived latency across a mixed fleet: shared CI runners that may sit idle for hours between jobs, and developer laptops where interactive builds benefit from a warm server. Persistent workers for Java, Scala, and Kotlin keep language servers alive across builds, but aggressive server shutdown can negate their warm-start benefits. Remote caching and remote execution can amortize cold-start costs, yet introduce network egress and storage fees that may exceed local build costs for very low traffic.
--max_idle_secs values have teams adopted for shared CI runners versus developer workstations, and what metrics guided those choices?--keep_state_after_build alongside a longer idle timeout meaningfully reduce re-analysis time without inflating idle memory beyond acceptable limits?31775 reputation · 29 Apr 2022, 20:30 UTC
For mixed CI/developer fleets, set a shorter idle timeout on shared CI runners (e.g., 300–600 s) and a longer timeout on developer workstations (e.g., 1800–3600 s). Keep --keep_state_after_build enabled on workstations to preserve the analysis cache, while leaving it disabled (default) on CI to avoid stale state.
The reduced default (--max_idle_secs=1800) targets idle‑resource savings in sporadic CI use. Developer workflows benefit from a warm persistent‑worker pool, so raising the timeout reduces cold‑start JVM warm‑up and re‑analysis time.
bazel--max_idle_secs changed from 10800 s to 1800 s.--nokeep_state_after_build is now the default, discarding the analysis cache after each build..bazelrc file scoped to that host:# CI runner .bazelrc
build --max_idle_secs=300
build --nokeep_state_after_build
# Developer workstation .bazelrc
build --max_idle_secs=1800
build --keep_state_after_build
bazel info max_idle_secs after a build.bazel shutdown logs or top to see memory/CPU impact.If you observe that CI jobs are spaced farther apart than the chosen timeout (e.g., >30 min idle), you may need to raise the CI value; otherwise the current split is sufficient. Please share the typical idle interval between builds on your CI runners to confirm the recommendation.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 29 Apr 2022, 22:20 UTC
When the Bazel server shuts down due to --max_idle_secs, the on‑disk action cache remains intact; only the in‑memory Skyframe analysis cache and any persistent worker processes are lost. Consequently, a warm server primarily reduces re‑analysis time and worker start‑up latency, while action execution benefits from the existing cache regardless of server state. This distinction helps explain why extending the idle timeout on developer workstations yields noticeable latency gains for incremental builds, whereas CI runners see mainly memory savings from more frequent shutdowns.