Repository navigation
searcher: accept storageSize in M, Mi, G and 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 in its own file under templates/_helpers/. It accepts a whole number of M, Mi, G or Gi and fails the render on anything else, unless searcher.autoCacheSize is enabled (the env vars are omitted in that case). Co-authored-by: Amp <amp@ampcode.com> Amp-Thread-ID: https://ampcode.com/threads/T-01a146da-9505-715c-949c-1146cc4e7e33
marcleblanc2
force-pushed
the
searcher-storagesize-g-units
branch
from
October 16, 2026 22:39
c3ca70d to
e203311
Compare
marcleblanc2
changed the title
Contributor
|
I don't mind this, but it seems like it might be a little auto magic for the style we typically take with our manifests. I'd like to get a second opinion from someone else on the team, wdyt @filiphaftek ? |
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
2 participants
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.
This PR fixes the issue for impacted customers without requiring them to make a change to their deployment, beyond upgrading.
Problem
SEARCHER_CACHE_SIZE_MBandSYMBOLS_CACHE_SIZE_MBassumes theGisuffix on searcher.storageSize150G) casts to0, so both env vars render as"0"0as "never evict"searcher.storageSize: 150Gafter upgrading 6.5.0 → 7.2.0Fix
sourcegraph.searcher.cacheSizeMBhelper intemplates/_helpers/_searcherCacheSize.tplaccepts a whole number ofM,Mi,GorGiand returns 45% of it in MB (treating binary units as decimal, as the oldGi * 450math did, so existingGivalues render identically)searcher.autoCacheSize=true, instead of silently disabling evictionsearcher.StatefulSet.yamlcall the helper; the default26Gistill renders11700values.yamlcomment, README (helm-docs), CHANGELOG, and a newsearcherCacheSize_test.yamlunittest suiteVerification
searcher.storageSize26Gi)1170011700100Gi4500045000150G0(no eviction)67500500000M0(no eviction)22500025Mi0(no eviction)111Ti,1.5G0(no eviction)1Ti+autoCacheSize: true