-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Cache and Eviction, Statistics
-
None
-
Storage Engines - Transactions
-
182.809
-
SE Transactions - 2026-11-06
-
None
Background
FTDC cannot show where the eviction server thread spends its time. There is no breakdown between scanning handles, walking trees, sorting candidates and waking waiting threads.
Statistics to add
Cumulative time statistics in microseconds, recorded on the eviction server thread. A refill is one call of _wti_evict_lru_walk that gets past the early exit for full queues. It consists of, in order: the handle scan with its tree visits (_wti_evict_walk), the sort and candidate selection under the queue lock, and the wake of waiting threads.
- Time in all tree visits: clock read before and after each __evict_walk_tree.
- Time in the sort and candidate selection.
- Time in the wake at the end of the refill.
- Time in the whole refill, and the refill count.
The handle scan with every skip is the difference between the refill time and the other three, so no clock read per skip is needed. Microseconds per refill and per queued page are derivable from these.
Cost
About 4 clock reads per refill and 2 per tree visit, all on the server thread. Not measured. If the cost is visible, time one visit in 16 and scale.
Definition of done
- A Python test checks that the refill count and the times increase when pages are queued, and that the visit, sort and wake times together do not exceed the refill time.
- Cost of the clock reads measured. Pages queued per second shows no measurable change with statistics enabled versus disabled.
- Statistics described in stat_data.py (s_all clean).
- Backport to 8.0. The change is small and limited to the eviction server; on 8.0 the code is in evict_lru.c.
Related: WT-18829
- related to
-
WT-18829 Eviction candidate supply is capped when dirty content is spread across many trees (high data handle count)
-
- Open
-