You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Metadata cache never shrinks and isn't counted against max_size #461
Everything the proxy stores in the metadata cache stays there for good. cacheMetadataBlob (internal/handler/handler.go:1423) writes the body to _metadata/<ecosystem>/... and upserts a metadata_cache row (internal/database/queries.go:1151/1168), but nothing ever deletes either. max_size eviction doesn't see them: GetTotalCacheSize only sums artifacts.size (queries.go:461), and evictLRU (internal/server/eviction.go:44) only walks artifacts. Retention only covers artifacts too.
So disk use from metadata only grows, and any client that can reach the proxy decides how fast. With npm or PyPI it takes many package names to make a dent. With the Go checksum database from #409 it's easier: tile paths can be counted through, and sum.golang.org currently has about 268k hash tiles (8 KiB each, ~2 GB) and as many data tiles (~50 KB each, ~13 GB). The go command itself only fetches a handful per build, but a script walking tile/8/0/NNN and tile/8/data/NNN fills the disk and none of it is ever freed.
Possible directions: count metadata in max_size and evict it LRU like artifacts (needs a last-used time on metadata_cache), or drop entries that haven't been read for some time. For the checksum database alone, not caching data tiles would remove most of the volume, since the go command never asks for them.
Since #462, checksum database data tiles are forwarded without being stored; hash tiles and all other metadata still accumulate.
Activity