searcher: accept storageSize in G as well as Gi for cache sizing - #948
Open
marcleblanc2 wants to merge 1 commit into
Open
marcleblanc2 wants to merge 1 commit into
marcleblanc2 wants to merge 1 commit into
Conversation
SEARCHER_CACHE_SIZE_MB and SYMBOLS_CACHE_SIZE_MB were derived with trimSuffix "Gi" | mul 450, so a storageSize like 150G left a non-numeric string that sprig cast to 0. searcher treats 0 as "never evict", so both caches grew unbounded until the PVC filled and the pod failed to start with "failed to setup TMPDIR: ... no space left on device". Move the math into a sourcegraph.searcher.cacheSizeMB helper that accepts a whole number of G or Gi and fails the render on anything else, unless searcher.autoCacheSize is enabled (env vars are omitted in that case). Amp-Thread-ID: https://ampcode.com/threads/T-01a0ca05-5e6e-769c-9aec-5f4e207ddb9b Co-authored-by: Amp <amp@ampcode.com>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
SEARCHER_CACHE_SIZE_MBandSYMBOLS_CACHE_SIZE_MBwere derived withtrimSuffix "Gi" .Values.searcher.storageSize | mul 450. AstorageSizein any other unit (e.g.150G) left a non-numeric string that sprig'smulcast to0, so both env vars rendered as"0".searcher treats
0as "never evict" (cache_evicter.go), and since"0"counts as explicitly set (config.go) the 45% auto-sizing from sourcegraph/sourcegraph#10040 never kicks in either. Both caches grow unbounded until the PVC fills and the pod fails to start:Seen on a customer instance with
searcher.storageSize: 150Gafter upgrading 6.5.0 → 7.2.0. The template has behaved this way since #677, so the disk had been filling for months; the upgrade restart just exposed it.Fix
sourcegraph.searcher.cacheSizeMBhelper accepts a whole number ofGorGiand multiplies by 450 (45% of the volume, treating 1 Gi ≈ 1000 MB as before, so existingGivalues render identically).searcher.autoCacheSize=true, instead of silently disabling eviction.searcher.StatefulSet.yamlcall the helper; the default26Gistill renders11700.values.yamlcomment, README (helm-docs), CHANGELOG, and a newsearcherCacheSize_test.yamlunittest suite.Verification
searcher.storageSize26Gi)1170011700100Gi4500045000150G0(no eviction)675001Ti0(no eviction)1Ti+autoCacheSize: trueNote:
scripts/helm-docs.shdownloads an x86_64 helm-docs 1.7.0 that does not run on Apple Silicon; README was regenerated with helm-docs 1.14.2 and the diff limited to thesearcher.storageSizerow.