Hi @Tejas_Jadhav1 welcome to the community!
The two eviction metrics are for internal WT use (eviction is an internal WT process), where it’s mainly used by MongoDB engineers to troubleshoot issues. However, they are used in combination with other metrics, and rarely, if ever, used as a standalone metric.
Typically if they are showing large numbers like what you posted (I would consider millions of anything as large ), it means that the server is trying hard to process backlog of work, i.e. it’s overwhelmed, and is trying to stay on top of the work it’s given.
There are many improvements made to WT over the years since version 3.6.2 was released in Jan 2018, including many performance improvements that make the eviction process smarter & more efficient. Also, the 3.6 series was not supported anymore as per April 2021. I would strongly encourage you to upgrade to the latest supported version (4.2 is the oldest series still supported), but upgrading to the latest version (currently 5.0.9) is best.
Upgrading to the latest version would also ensure that you don’t experience old bugs that was already fixed.
As per Replica Set Deployment Architectures, it’s not recommended to deploy an even number of members. If you have 2 data bearing nodes, I recommend you remove the Arbiter from the replica set.
Would there be any data loss in case of server restart?
Unless you do a kill -9 of the
mongod process, and you’re using majority write concern for your writes, there should be no risk of data loss, unless it’s hardware related.