Hi team, we are using MongoDB server version 5.0.10.
In the past few weeks, we have seen a spike in Page evicted by application threads, and coincidentally at the same time a spike in Operational Latencies (Writes and Reads).
The number of pages evicted during the operational latency spikes - 10k.
When going through the cache eviction documentation of WiredTiger, we came across the trigger values when application threads are supposed to be used in page eviction process.
When cache size hits 95%
When the dirty pages reach 20%
The attached figures below are the cache sizes and dirty pages at the instance when application threads are being used:
Cache percentage - 80%
Dirty Page percentage - 1.4%
The values are clearly under the threshold, is there any other reason why the application threads were used? How can we tune the mongoDB to fix this issue?
Please note : current cache eviction threads being used are the default set by MongoDB (4).
Hi @Uddeshya_Singh and welcome to MongoDB community forums!!
As mentioned in the Cache and eviction tuning, the eviction would begin when the threshold values are reached.
The cache serves as a valuable intermediary between application operations and disk I/O. WiredTiger, the system in question, strives to maintain cache usage at a maximum of 80%. Pushing the cache to its limit of 95% could introduce latency issues within the application.
However, in your case, since you are seeing evection at 80% of the cache utilisation might be a result of other operations which are utilising the cache.
There might be more than one reason when you seeing the increase and latency in your application.
A background process which might be performing some computations.
A concurrent process which is utilising the application thread.
A sudden increase in the workload.
I would recommend taking a look at the application with the above mentioned scenarios.
If, however, you are unable to resolve, you can reach out to MongoDB Support Hub for more detailed troubleshooting and observations.
