When the ingest table on the standby grows too large or there are too many updates on a single key, we use application threads to trigger forced eviction. However, these forced eviction attempts achieve limited progress except for splitting the pages because a new checkpoint has not been established, preventing garbage collection of any data from the page. As a result, replication on the standby slows down significantly, leading to performance degradation and causing the standby to fall behind, even under light cache utilization.

Investigate potential solutions to address and improve this issue.

This is manifested in a tsbs workload. The patch build change in MongoDB reproduces the issue consistently.

In this particular case,

We currently perform forced eviction for two reasons: the size of a page or the number of updates on a single key. However, I believe forced eviction should not be triggered in the latter case, as there is nothing to garbage collect, making it entirely inefficient and wasteful. For the first scenario, where eviction is due to page size, we should aim to handle it in the background rather than relying on application threads, especially under light cache utilization.