We have observed in a YCSB 100% update workload, that increasing the number of background eviction threads reduces the throughput of the benchmark.

On closer inspection, it appears as though the rate of write-back in the benchmark is unnecessarily high. The overall throughput is about 8k user operation, which translates into about 32k WiredTiger transactional changes. WiredTiger isn't the bottleneck for the workload - the background flushing is primarily taking advantage of the workload to keep the cache in a healthy state.

If more worker threads are added, it writes more pages back. When more pages are written back application threads more often end up waiting for evictions to finish before they can make further changes.

The scope of this ticket is to explore reducing the volume of dirty write back in a lightly loaded system. The trick will be in identifying a lightly loaded system.