Most UNIX-like operating systems, including Linux and OS X, provide
ways to limit and control the usage of system resources such as
threads, files, and network connections on a per-process and per-user
basis. These “ulimits” prevent single users from using too many system
resources. Sometimes, these limits have low default values that can
cause a number of issues in the course of normal MongoDB operation.

Note

Red Hat Enterprise Linux and CentOS 6 place a max process
limitation of 1024 which overrides ulimit settings. Create a
file named /etc/security/limits.d/99-mongodb-nproc.conf with
new softnproc and hardnproc values to increase the
process limit. See /etc/security/limits.d/90-nproc.conf file as
an example.

mongod and mongos each use threads and file
descriptors to track connections and manage internal operations. This
section outlines the general resource utilization patterns for MongoDB.
Use these figures in combination with the actual information about your
deployment and its use to determine ideal ulimit settings.

mongos instances maintain a connection pool to each shard
so that the mongos can reuse connections and quickly
fulfill requests without needing to create new connections.

You can limit the number of incoming connections using
the maxIncomingConnections run-time option.
By restricting the number of incoming connections you can prevent a
cascade effect where the mongos creates too many
connections on the mongod instances.

ulimit refers to the per-user limitations for various
resources. Therefore, if your mongod instance executes as a
user that is also running multiple processes, or multiple
mongod processes, you might see contention for these
resources. Also, be aware that the processes value (i.e. -u)
refers to the combined number of distinct processes and sub-process
threads.

You can change ulimit settings by issuing a command in the
following form:

There are both “hard” and the “soft” ulimits that affect MongoDB’s
performance. The “hard” ulimit refers to the maximum number of
processes that a user can have active at any time. This is the
ceiling: no non-root process can increase the “hard” ulimit. In
contrast, the “soft” ulimit is the limit that is actually
enforced for a session or process, but any process can increase it
up to “hard” ulimit maximum.

A low “soft” ulimit can cause can'tcreatenewthread,closingconnection errors if the number of connections
grows too high. For this reason, it is extremely important to set
bothulimit values to the recommended values.

ulimit will modify both “hard” and “soft” values unless the
-H or -S modifiers are specified when
modifying limit values.

For many distributions of Linux you can change values by substituting
the -n option for any possible value in the output of ulimit-a. On OS X, use the launchctllimit command. See your
operating system documentation for the precise procedure for changing
system limits on running systems.

After changing the ulimit settings, you must restart the
process to take advantage of the modified settings. You can use the
/proc file system to see the current limitations on a running
process.

Depending on your system’s configuration, and default settings, any
change to system limits made using ulimit may revert following
system a system restart. Check your distribution and operating
system documentation for more information.

Note

SUSE Linux Enterprise Server 11, and potentially other versions of SLES
and other SUSE distributions, ship with virtual memory address space limited
to 8GB by default. This must be adjusted in order to prevent virtual memory
allocation failures as the database grows.

The SLES packages for MongoDB adjust these limits in the default scripts,
but you will need to make this change manually if you are using custom
scripts and/or the tarball release rather than the SLES packages.

For Linux distributions that use systemd, you can specify
limits within the [Service] sections of service scripts if you
start mongod and/or
mongos instances as systemd services. You can do this
by using resource limit directives.

The /proc file-system stores the per-process limits in the
file system object located at /proc/<pid>/limits, where <pid>
is the process’s PID or process identifier. You can use the
following bash function to return the content of the limits
object for a process or processes with a given name: