SmartStore Cache Eviction on Low‑Traffic Indexes: Uncertain Search Latency

The goal is to reduce on‑premise storage costs for a low‑traffic Splunk Enterprise 9.x deployment by moving infrequently accessed data to SmartStore while maintaining acceptable search latency.

A key constraint is that the index receives only a few megabytes of events per day, so the cache manager may evict data frequently when the configured max_cache_size is exceeded. This could cause repeated cold‑bucket fetches and unpredictable latency spikes.

The current documentation does not detail how eviction decisions are made for such sparse workloads, nor does it provide guidance on tuning cache thresholds to balance cost savings against performance. Monitoring tools expose hit ratios, but interpreting them for low‑traffic scenarios remains unclear.

What eviction policy does SmartStore use when max_cache_size is exceeded on a low‑traffic index? How can we accurately monitor cache hit ratios for these indexes? Is there a recommended max_cache_size threshold or configuration to avoid frequent evictions while keeping storage costs minimal?