Production Notes

Backups
TCP Port Numbers
Linux

General Unix Notes
Linux Kernel Versions
Checking Disk IO
Checking Network IO

Storage

Solid State Disks (SSDs)
RAID
Linux File Systems
Remote mounts

What Hardware?
Tips

Backups

TCP Port Numbers

Default TCP port numbers for MongoDB processes:

Standalone mongod : 27017
mongos : 27017
shard server (mongod --shardsvr) : 27018
config server (mongod --configsvr) : 27019
web stats page for mongod : add 1000 to port number (28017, by default)

Linux

General Unix Notes

Turn off atime for the data volume
Set file descriptor limit and user process limit to 4k+ (see etc/limits and ulimit)
Do not use large VM pages with Linux (more info)
Use dmesg to see if box is behaving strangely
Try to disable NUMA in your BIOS. If that is not possible see NUMA
Minimize clock skew between your hosts by using ntp; linux distros usually include this by default, but check and install the ntpd package if it isn't already installed

Linux Kernel Versions

Some have reported skepticism on behavior of Linux 2.6.33-31 and 2.6.32 kernel. 2.6.36 is given a thumbs up by the community.

For those running databases on ext4 filesystems, a 2.6.23 kernel is required for efficient filesystem preallocation, 2.6.25 is required for XFS support of the same feature. High filesystem I/O following the allocation of new database files is one symptom of this problem.

Checking Disk IO

iostat -txm 2

If the timestamp feature is not available, iostat -xm 2

Checking Network IO

atop - Holistic system top
Munin
ethtool eth0 - check network port speed
bwm-ng
iptraf

Storage

Solid State Disks (SSDs)

See SSD page

RAID

Typically we recommend using RAID-10.

RAID-5 and RAID-6 can be slow.

See also the ec2 page for comments on EBS striping.

Linux File Systems

MongoDB uses large files for storing data, and preallocates these. These filesystems seem to work well:

ext4 ( kernel version >= 2.6.23 )
xfs ( kernel version >= 2.6.25 )

In addition to the file systems above you might also want to (explicitly) disable file/directory modification times by using these mount options:

noatime (also enables nodiratime)

We have found ext3 to be very slow in allocating files (or removing them) as well as access within large files is also poor.

Remote mounts

We have found that some versions of NFS perform very poorly and do not recommend using NFS. See the NFS page for more information.

Amazon elastic block store (EBS) seems to work well up to its intrinsic performance characteristics, when configured well.

What Hardware?

MongoDB tends to run well on virtually all hardware. In fact it was designed specifically with commodity hardware in mind (to facilitate cloud computing); that said it works well on very large servers too. That said if you are about to buy hardware here are a few suggestions:

Fast CPU clock speed is helpful.
Many cores helps but does not provide a high level of marginal return, so don't spend money on them. (This is both a consequence of the design of the program and also that memory bandwidth can be a limiter; there isn't necessarily a lot of computation happening inside a database).
NUMA is not very helpful as memory access is not very localized in a database. Thus non-NUMA is recommended; or configure NUMA as detailed elsewhere in this document.
RAM is good.
SSD is good. We have had good results and have seen good price/performance with SATA SSDs; the (typically) more upscale PCI SSDs work fine too.
Commodity (SATA) spinning drives are often a good option as the speed increase for random I/O for more expensive drives is not that dramatic (only on the order of 2x) – spending that money on SSDs or RAM may be more effective.