The replication oplog window should cover normal maintenance and
downtime windows to avoid the need for a full resync.

The replication oplog window should cover the time needed to
restore a replica set member from the last backup.

Changed in version 3.4: The replication oplog window no longer needs to cover the
time needed to restore a replica set member via initial sync
as the oplog records are pulled during the data copy.
However, the member being restored must have enough disk
space in the local
database to temporarily store these oplog records for the
duration of this data copy stage.

With earlier versions of MongoDB, replication oplog window
should cover the time needed to restore a replica set member
by initial sync.

Ensure that your replica set includes at least three data-bearing
nodes that run with journaling and that you issue writes
with w:"majority"write concern for availability and durability.

Use hostnames when configuring replica set members, rather than IP
addresses.

Ensure full bidirectional network connectivity between all
mongod instances.

Ensure that each host can resolve itself.

Ensure that your replica set contains an odd number of voting members.

Place your config servers on dedicated hardware for
optimal performance in large clusters. Ensure that the hardware has
enough RAM to hold the data files entirely in memory and that it
has dedicated storage.

Place the journal on its own low-latency disk for write-intensive
workloads. Note that this will affect snapshot-style backups as the
files constituting the state of the database will reside on
separate volumes.

For the MMAPv1 storage engine, if your working set is bigger that the
available RAM, and the document access pattern is random, consider
lowering the readahead to 32 or 16. Evaluate different settings to find
an optimal value that maximizes the resident memory and lowers the
number of page faults.

For the WiredTiger storage engine, set readahead to 0 regardless of
storage media type (spinning, SSD, etc.). In
general, use the recommended readahead setting unless testing shows a
measurable, repeatable, and reliable benefit in a higher readahead
value. MongoDB Professional Support can
provide advice and guidance on non-zero readahead configurations.

Disable the tuned tool if you are running RHEL 7 / CentOS 7 in a
virtual environment.

When RHEL 7 / CentOS 7 run in a virtual environment, the tuned tool
automatically invokes a performance profile derived from
performance throughput, which automatically sets the readahead
settings to 4MB. This can negatively impact performance.

Adjust the ulimit values on your hardware to suit your use case. If
multiple mongod or mongos instances are
running under the same user, scale the ulimit values
accordingly. See: UNIX ulimit Settings for more information.

Configure sufficient file handles (fs.file-max), kernel pid
limit (kernel.pid_max), maximum threads per process
(kernel.threads-max), and maximum number of memory map areas per
process (vm.max_map_count) for your deployment. For large systems,
the following values provide a good starting point:

fs.file-max value of 98000,

kernel.pid_max value of 64000,

kernel.threads-max value of 64000, and

vm.max_map_count value of 128000

Ensure that your system has swap space configured. Refer to your
operating system’s documentation for details on appropriate sizing.

Ensure that the system default TCP keepalive is set correctly. A
value of 300 often provides better performance for replica sets and
sharded clusters. See: Does TCP keepalive time affect MongoDB Deployments? in the Frequently Asked
Questions for more information.