-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Cache and Eviction
-
None
-
Storage Engines - Transactions
-
304.93
-
SE Transactions - 2026-11-06
-
3
Problem
Threads that find the eviction queue empty wait on evict_threads.wait_cond (10 ms timeout). Every refill ends with _wt_cond_signal on that condition, which is a pthread_cond_broadcast, so the eviction server pays the futex wake of every waiter while the queue is already full. Each urgent push (_wt_evict_page_urgent) queues one page and broadcasts on the same condition too.
On the WT-18829 reproducer (r27_t32, 96 cores, ~930 application threads, 609 refills/s) the refill broadcast is 19% of eviction-thread CPU, ~24% of server time. On the HELP-101149 primary, urgent pushes run at ~2,630/s against 541 refills/s in the stall mode, each waking all waiters for one page.
Prototype
Capping the refill wake at 64 counted signals on r27_t32 (3 alternated runs per side): +74% pages queued, +54% updates, mean wait per waiting operation 88 -> 56 ms. Every prototype run beat every base run. The urgent path was not changed in the prototype.
Proposed change
- Add __wt_cond_signal_n(session, cond, n) next to __wt_cond_signal: same barrier and no-waiter fast path, then n pthread_cond_signal calls under the condition mutex (Windows: WakeConditionVariable). Fall back to one broadcast when 4n >= 3 * waiters.
- Refill: n = max(1, min(waiters, pages queued by this refill)). No fixed cap.
- Urgent push: n = 1.
- Add a statistic for waiters sampled at each refill, so the customer gain can be projected without an estimate.
The wait side and other __wt_cond_signal callers do not change; a thread that is not woken still times out at 10 ms.
The 3/4 threshold comes from a condvar microbenchmark: on 96-core Graviton4 a broadcast costs ~2.0 us per waiter and a signal ~2.4 us per call, and signals win clearly up to queued/waiters = 0.5 and tie around 0.75 on both arm and x86.
Definition of done
- A/B on the WT-18829 reproducer, at least 3 alternated runs per side: r27_t32 shows higher pages queued/s and no worse wait per waiting operation.
- No regression on the few-large-trees control.
- Develop change compared against a develop baseline; backport to 8.0 measured on 8.0.
- is related to
-
WT-18971 Add statistics for the time an urgent eviction page waits in the queue
-
- Open
-
-
WT-19007 Make boolean eviction options reconfigurable in both directions
-
- Open
-
- related to
-
WT-18829 Eviction candidate supply is capped when dirty content is spread across many trees (high data handle count)
-
- Open
-