The default cache_max_bytes shrinks as the cache fills: each restart can evict most of the cache #184

Closed
opened 2026-10-04 15:08:35 +02:00 by clawbot · 1 comment
Collaborator

Found while reviewing #182 (#89). Checked against next at be6c715.

When cache_max_bytes is not set, ComputeDefaultCacheMaxBytes in internal/config/cachesize.go makes the limit 75% of the space free on the cache's filesystem at startup. The cache's own files are not free space, so the limit drops as the cache grows. On an otherwise empty 100 GB disk: the first start allows 75 GB; once the cache holds 75 GB, the next start sees 25 GB free and allows about 19 GB, and eviction deletes about 56 GB of cached images; the start after that allows about 61 GB again. A deployment that restarts on every deploy keeps throwing most of its cache away. README.md now tells operators to set cache_max_bytes, but the default should not behave like this.

Plan:

  • The default counts what the cache already holds as space it may use: 75% of (free space + the bytes the cache already holds), with the 500 MiB floor as now. What the cache holds comes from the cache's own size accounting where the cache is opened (Cache.UsageBytes in internal/imgcache), not from walking the directories at startup; so the default is worked out there, after the database is open, and logged as now.
  • Test first: with a fake free-space probe and a cache already holding N bytes, the default is 75% of (free + N), so a full cache keeps its limit across a restart.
  • README.md, where it describes the default, says what it counts; the advice to set cache_max_bytes for a lasting deployment may stay.

Model: opus-5-5

Found while reviewing https://git.eeqj.de/sneak/pixa/pulls/182 (https://git.eeqj.de/sneak/pixa/issues/89). Checked against `next` at `be6c715`. When `cache_max_bytes` is not set, `ComputeDefaultCacheMaxBytes` in `internal/config/cachesize.go` makes the limit 75% of the space free on the cache's filesystem at startup. The cache's own files are not free space, so the limit drops as the cache grows. On an otherwise empty 100 GB disk: the first start allows 75 GB; once the cache holds 75 GB, the next start sees 25 GB free and allows about 19 GB, and eviction deletes about 56 GB of cached images; the start after that allows about 61 GB again. A deployment that restarts on every deploy keeps throwing most of its cache away. `README.md` now tells operators to set `cache_max_bytes`, but the default should not behave like this. Plan: - The default counts what the cache already holds as space it may use: 75% of (free space + the bytes the cache already holds), with the 500 MiB floor as now. What the cache holds comes from the cache's own size accounting where the cache is opened (`Cache.UsageBytes` in `internal/imgcache`), not from walking the directories at startup; so the default is worked out there, after the database is open, and logged as now. - Test first: with a fake free-space probe and a cache already holding N bytes, the default is 75% of (free + N), so a full cache keeps its limit across a restart. - `README.md`, where it describes the default, says what it counts; the advice to set `cache_max_bytes` for a lasting deployment may stay. Model: opus-5-5
Author
Collaborator

Built in #188: when cache_max_bytes is omitted, the cache now works out the default when it opens, as 75% of the sum of the free space and what it already holds, at least 500 MiB. The PR body lists what moved and the disclosures.

Model: opus-5-5

Built in https://git.eeqj.de/sneak/pixa/pulls/188: when `cache_max_bytes` is omitted, the cache now works out the default when it opens, as 75% of the sum of the free space and what it already holds, at least 500 MiB. The PR body lists what moved and the disclosures. Model: opus-5-5
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: sneak/pixa#184