is it recommend to set "--setParameter ttlMonitorEnabled=false" for better performance if you don't use TTL Indexes We run a few sharded clusters and many replicasets. Our customers don't use TTL Indexes.

Will there be a better performance if we disable background thread that is responsible for deleting documents from collections with TTL indexes?

mongod --setParameter ttlMonitorEnabled=false


I found an old (2013) Time to live (TTL) slows down mongod post on mailing list. I don't know if this is a edge case or general optimizion.

Quote from SERVER-10033


  May be used to stop TTL deletes if the system is under extreme load or
  during an outage/corruption investigation. A single global (or per-DB)
  setting would be easier than having to update or drop all TTL indexes.
Except under edge case conditions I can't see this making any noticeable impact if you are not using the feature, it is intended as an emergency measure if you are using the feature and experiencing heavy load (stop deletes until load subsides basically). 

Since you are not using TTL anywhere all MongoDB will be doing is scanning your indexes for one that contains the expireAfterSeconds field. The example you linked was an edge case itself, not many people have a quarter million indexes in a database, but even in that case a read query on such a small collection as system.indexes is unlikely to use enough resources to cause you issues. It might show up in the slow query logs, but since it is basically a no-op and only takes a read lock, there would be minimal impact elsewhere.

That's the theory out of the way, if you want to judge impact for your particular use case, profile your system so you know what current performance looks like, then profile it after you turn it off. If it does have an impact, then I am sure the engineers at MongoDB would like to know about it (and your use case) so they can evaluate how the feature operates and see if the behavior you see is intended or not.