-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
None
-
Storage Engines - Transactions
-
Fully Compatible
-
ALL
-
None
-
None
-
None
-
None
-
None
-
None
-
None
Overview
The test jstests/noPassthrough/txns_cache_errors/transaction_aborted_under_cache_pressure.js hangs due to a mismatch between cache size and the more efficient eviction introduced by WT-17598 (SKIP_CACHE_INCR optimization).
Background
WT-17598 introduced WT_SESSION_SKIP_CACHE_INCR, batching per-update atomic cache counter increments during prepared-update page restore from O(N) to O(1). This makes eviction more efficient, so the 256MB cache can be partially reclaimed during normal operation.
MongoDB cache pressure detection requires two simultaneous conditions:
- threadPressureResult: eviction stall >95% of thread time AND txnsCommittedCount == 0 for >1 second
- cacheRatioResult: bytes_updates/bytes_max > 10% OR bytes_dirty/bytes_max > 20%
With 256MB and more efficient eviction, internal MongoDB transactions (oplog writes, heartbeats) continue committing between eviction cycles, so txnsCommittedCount never drops to 0 within the 10-minute timeout.
Fix
Reduce cache_size from 256M to 64M in the test's wiredTigerEngineConfigString. With 64MB and 0.5MB documents, ~128 open transactions fill the cache completely, stalling all threads including oplog writers, causing txnsCommittedCount to drop to 0 and meeting both detection conditions reliably.
Scope of Work
- jstests/noPassthrough/txns_cache_errors/transaction_aborted_under_cache_pressure.js — change cache_size=256M to cache_size=64M
- is related to
-
WT-17598 Batch per-update cache atomics in __wti_page_inmem_updates
-
- Closed
-