# Cache-pressure early bucket closure and bucket catalog memory > Source-anchored research for Cache-pressure early bucket closure and bucket catalog memory. Run status: COMPLETED. Parent: [Bucket fragmentation remediation (re-insert/merge)](https://llms-explorer.com/tree/bucket-fragmentation-remediation-re-insert-merge/) · 4 facets · 13 facts · page: https://llms-explorer.com/tree/cache-pressure-early-bucket-closure-and-bucket-catalog-memory/ ## How it works - MongoDB's time-series server README says `timeseriesIdleBucketExpiryMemoryUsageThreshold` triggers archiving or closure of idle buckets when BucketCatalog memory exceeds its threshold. Archiving removes most in-memory bucket state but keeps a small record; if archiving all idle buckets is insufficient, the catalog removes archived entries. (high confidence) (verified as of 2026-10-14) — [source](https://raw.githubusercontent.com/mongodb/mongo/master/src/mongo/db/timeseries/README.md) ## Measurements and reference values - Do not treat 3 GB as a documented universal BucketCatalog cap: the feedback submitter labels that figure a guess, the current manual describes the default allocation as 2.5% of available system memory, and the server README identifies `timeseriesIdleBucketExpiryMemoryUsageThreshold` as the controlling parameter. (medium confidence) (verified as of 2026-10-19) — [source](https://feedback.mongodb.com/ideas/CUSTOMER-I-7595) - A July 2026 deployment report describes MongoDB 6.0.x on a 4GB VM with 17,000 sites: a backfill produced 3,459,670 `numBucketsClosedDueToMemoryThreshold` closures and about one measurement per commit. After the author set `timeseriesIdleBucketExpiryMemoryUsageThreshold` to 512MB and reset the collection, the bucket count was 17,000. This is one workload-specific result; it does not establish a safe threshold for other hosts or show that the setting changes `numBucketsClosedDueToCachePressure`. (low confidence) (verified as of 2026-07-16) — [source](https://sangkihan.github.io/posts/mongodb-timeseries-migration/) ## Problems, failure modes and limitations - MongoDB's tracking-allocator issue says BucketCatalog memory use had been estimated and error-prone, and records the allocator work as fixed for 7.3.0-rc0. The current server README says the Tracking Allocator calculates memory use for the BucketCatalog and related time-series internals. (medium confidence) (verified as of 2024-01-19) — [source](https://jira.mongodb.org/browse/SERVER-85291) - MongoDB v8.0 documents two different closure counters: `numBucketsClosedDueToMemoryThreshold` counts closures when active buckets do not fit the allowed BucketCatalog cache size, while `numBucketsClosedDueToCachePressure` counts closures when a bucket exceeds a dynamic size limit derived from storage-engine cache size and tracked `numBuckets`. The cache-pressure limit is distinct from the ordinary maximum bucket size. (high confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.0/reference/command/serverstatus/) - MongoDB v8.0 sets the ordinary bucket cap at 1,000 measurements or 125KB, whichever is lower, and says high-cardinality workloads may receive a lower cap so the bucket working set fits in WiredTiger cache. A MongoDB Community load-test report illustrates the fragmentation risk: a Type 2 chunk loaded after work in other collections produced 420,000 buckets, one average measurement per commit, and 415,000 cache-pressure closures; loading the chunk first produced 25,000 buckets and 17 average measurements per commit. The poster reported at least three times more space in the fragmented run. (medium confidence) (verified as of 2026-10-23) — [source](https://www.mongodb.com/docs/v8.0/core/timeseries/timeseries-limitations/) ## Facts and statements - MongoDB documents two distinct memory-related closure conditions: the active-bucket set does not fit in the storage-engine cache, or the BucketCatalog exceeds its total memory allocation. A closed bucket can no longer accept writes, but its data remains available for queries. (high confidence) — [source](https://www.mongodb.com/docs/manual/core/timeseries/timeseries-bucketing/) - A MongoDB Community report describes poor packing under interleaved, high-cardinality load: a chunk with 25,000 metadata pairs produced about 420,000 buckets, an average of one measurement per commit, and 415,000 cache-pressure closures; the same chunk loaded before the competing workload produced 25,000 buckets and 17 measurements per commit. A separate Jira report also records one-measurement buckets associated with cache-pressure closures. (medium confidence) (verified as of 2025-03-03) — [source](https://www.mongodb.com/community/forums/t/suboptimal-bucket-creation-in-timeseries-collection-due-to-cache-pressure/249863) - In a 2026 deployment report, a workload with 17,000 sites reporting every five minutes produced near one-to-one bucket-to-measurement counts while memory-threshold closures dominated. The author later reported zero such closures and 408,000 daily buckets after setting the threshold to 512 MiB and using one-hour bucket spans; this is one workload result, not a universal tuning guarantee. (medium confidence) (verified as of 2026-07-16) — [source](https://sangkihan.github.io/posts/mongodb-timeseries-migration/) - The SERVER-89233 issue scopes one cache-pressure fragmentation regression to MongoDB 7.0.4 and 7.0.5 and records fix versions 8.0.5 and 8.1.0-rc0. That fix record applies to the tracked regression; it does not establish that all memory-triggered early closures disappeared. (low confidence) (verified as of 2025-04-25) — [source](https://jira.mongodb.org/browse/SERVER-89233) - MongoDB's v8.0 `serverStatus` documentation lists `numBucketsClosedDueToMemoryThreshold` and `numBucketsClosedDueToCachePressure` as separate bucket-catalog fields. SERVER-89233 reports the cache-pressure counter, while a 2026 deployment report gives the memory-threshold counter. Those reports do not establish that the counters are interchangeable; compare each using the definition for the deployed server release. (medium confidence) (verified as of 2026-07-16) — [source](https://jira.mongodb.org/browse/SERVER-89233) - MongoDB Jira `SERVER-89233` records a sharded-cluster case where cache pressure produced about one bucket per document. The issue lists affected versions 7.0.4 and 7.0.5 and fix versions 8.0.5 and 8.1.0-rc0. This is a version-scoped bug report, not evidence that cache-pressure closure always produces singleton buckets. (medium confidence) (verified as of 2025-04-25) — [source](https://jira.mongodb.org/browse/SERVER-89233) - A July 2021 +N Consulting walkthrough showed `collStats().timeseries` closure counters for memory threshold, time forward, count, and size, while the author said the counters' meaning was not yet clear to them. MongoDB v8.0 now documents separate meanings for memory-threshold and cache-pressure closures, so diagnosis should use the definitions for the server version being run. (medium confidence) (verified as of 2026-10-23) — [source](https://www.plusnconsulting.com/post/Time-Series-Collections-Native-Support/index.html)