- Administration >
- MongoDB Performance >
- UNIX
ulimitSettings
UNIX ulimit Settings¶
On this page
Most UNIX-like operating systems, including Linux and macOS, 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.
Resource Utilization¶
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.
Generally, all mongod and mongos instances:
- track each incoming connection with a file descriptor and a thread.
- track each internal thread or pthread as a system process.
mongod¶
- 1 file descriptor for each data file in use by the
mongodinstance. - 1 file descriptor for each journal file used by the
mongodinstance whenstorage.journal.enabledistrue. - In replica sets, each
mongodmaintains a connection to all other members of the set.
mongod uses background threads for a number of internal
processes, including TTL collections,
replication, and replica set health checks, which may require a small
number of additional resources.
mongos¶
In addition to the threads and file descriptors for client connections,
mongos must maintain connections to all config servers and
all shards, which includes all members of all replica sets.
For mongos, consider the following behaviors:
mongosinstances maintain a connection pool to each shard so that themongoscan reuse connections and quickly fulfill requests without needing to create new connections.You can limit the number of incoming connections using the
net.maxIncomingConnectionsrun-time option. By restricting the number of incoming connections you can prevent a cascade effect where themongoscreates too many connections on themongodinstances.Note
Changed in version 2.6: MongoDB removed the upward limit on the
maxIncomingConnectionssetting.
Review and Set Resource Limits¶
ulimit¶
You can use the ulimit command at the system prompt to check
system limits, as in the following example:
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 failed to create service entry worker
thread for [x] errors if the number of connections grows too high. For this
reason, it is extremely important to set both ulimit 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 macOS, use the launchctl limit 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
a system restart. Check your distribution and operating
system documentation for more information.
SUSE Linux Enterprise Server¶
SUSE Linux Enterprise Server and potentially other SUSE distributions ship with virtual memory address space limited to 8 GB by default. You must adjust this in order to prevent virtual memory allocation failures as the database grows.
The SLES packages for MongoDB automatically adjust these limits in their default init script. If you are starting MongoDB manually without the provided init script, are using your own custom init script, or are using the TGZ tarball release, you must make these changes yourself.
Red Hat Linux Enterprise Server and CentOS¶
Red Hat Enterprise Linux and CentOS 6 and 7 enforce a separate max process
limitation, nproc, which overrides ulimit settings. This value is
defined in the following configuration file, depending on version:
| Version | Value | File |
|---|---|---|
| RHEL / CentOS 7 | 4096 | /etc/security/limits.d/20-nproc.conf |
| RHEL / CentOS 6 | 1024 | /etc/security/limits.d/90-nproc.conf |
To configure an nproc value for these versions, create a file named
/etc/security/limits.d/99-mongodb-nproc.conf with new soft nproc and
hard nproc values to increase the process limit. For recommended values,
see Recommended ulimit Settings.
Recommended ulimit Settings¶
Every deployment may have unique requirements and settings; however,
the following thresholds and settings are particularly important for
mongod and mongos deployments:
-f(file size):unlimited-t(cpu time):unlimited-v(virtual memory):unlimited[1]-l(locked-in-memory size):unlimited-n(open files):64000-m(memory size):unlimited[1] [2]-u(processes/threads):64000
Always remember to restart your mongod and
mongos instances after changing the ulimit settings to
ensure that the changes take effect.
Linux distributions using Upstart¶
For Linux distributions that use Upstart, you can specify limits
within service scripts if you start mongod and/or
mongos instances as Upstart services. You can do this by
using limit stanzas.
Specify the Recommended ulimit Settings, as in the following example:
Each limit stanza sets the “soft” limit to the first value specified and the “hard”
limit to the second.
After changing limit stanzas, ensure that the changes take
effect by restarting the application services, using the following
form:
Linux distributions using systemd¶
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.
Specify the Recommended ulimit Settings, as in the following example:
Each systemd limit directive sets both the “hard” and “soft” limits to the value
specified.
After changing limit stanzas, ensure that the changes take
effect by restarting the application services, using the following
form:
/proc File System¶
Note
This section applies only to Linux operating systems.
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:
You can copy and paste this function into a current shell session or load it as part of a script. Call the function with one the following invocations:
| [1] | (1, 2) If you limit virtual or resident memory size on a system running MongoDB the operating system will refuse to honor additional allocation requests. |
| [2] | The -m parameter to ulimit has no effect on
Linux systems with kernel versions more recent than 2.4.30. You may
omit -m if you wish. |