LRU Crawler vs Lazy Expiration: Choosing Reclamation Strategy Under High Write Throughput

When memcached runs under sustained high write throughput, expired items can accumulate and either waste memory or trigger premature evictions. Two documented reclamation paths exist: lazy expiration, which checks expiry only on item access, and the LRU crawler, a background thread that proactively scans and removes expired entries.

Enabling the crawler (-o lru_crawler) reduces the window that expired items occupy memory but adds CPU cycles and can increase contention on the global LRU locks, especially on many‑core systems. Lazy expiration avoids background overhead but lets stale items linger, potentially causing valid entries to be evicted under memory pressure.

A further complication arises when slab automove (-o slab_automove) reassigns pages between slab classes while the crawler is iterating; the exact interaction is not fully detailed in the official docs, making the combined behavior uncertain.

Which reclamation approach—or combination of tunables such as lru_crawler_sleep and lru_crawler_tocrawl—provides the best trade‑off for a workload with heavy writes and active slab automove? How can the crawler’s impact on LRU lock contention be measured in practice? Does the current source code guarantee safe page moves during a crawler scan?