- Frequently Asked Questions >
- FAQ: MongoDB Diagnostics
FAQ: MongoDB Diagnostics¶
This document provides answers to common diagnostic questions and issues.
Where can I find information about a mongod process that stopped running unexpectedly?¶
If mongod shuts down unexpectedly on a UNIX or UNIX-based platform, and if mongod fails to log a shutdown or error message, then check your system logs for messages pertaining to MongoDB. For example, for logs located in /var/log/messages, use the following commands:
sudo grep mongod /var/log/messages sudo grep score /var/log/messages
Does TCP keepalive time affect MongoDB Deployments?¶
If you experience socket errors between clients and servers or between members of a sharded cluster or replica set that do not have other reasonable causes, check the TCP keepalive value, which Linux systems store as tcp_keepalive_time. A common keepalive period is 7200 seconds (2 hours); however, different distributions and OS X may have different settings. For MongoDB, you will have better results with shorter keepalive periods, on the order of 120 seconds (two minutes).
If your MongoDB deployment experiences keepalive-related issues, you must alter the tcp_keepalive_time value on all machines hosting MongoDB processes. This includes all machines hosting mongos or mongod servers and all machines hosting client processes that connect to MongoDB.
Changed in version 2.0.
On Linux systems you can use the following operation to check the value of tcp_keepalive_time:
The value is measured in seconds. You can change the tcp_keepalive_time value with the following operation:
echo <value> > /proc/sys/net/ipv4/tcp_keepalive_time
For OS X systems, issue the following command to view the keep alive setting:
To set a shorter keep alive period use the following invocation:
sysctl -w net.inet.tcp.keepinit=<value>
The above methods of setting the TCP keepalive are not persistent; you will need to reset the new tcp_keepalive_time value each time you reboot or restart a system. see your operating system’s documentation for instructions on setting the TCP keepalive value persistently.
For Windows systems, issue the following command to view the keep alive setting:
reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime
The registry value is not present by default. The system default, used if the value is absent, is 7200000 milliseconds or 0x6ddd00 in hexadecimal. To set a shorter keep alive period use the following invocation in an Administrator Command Prompt, where <value> is expressed in hexadecimal (e.g. 0x0124c0 is 120000):
reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /v KeepAliveTime /d <value>
Windows users should consider the Windows Server Technet Article on KeepAliveTime for more information on setting keep alive for MongoDB deployments on Windows systems.
Changed in version 2.0.
You will need to restart mongod and mongos servers for new system-wide tcp_keepalive_time settings to take effect on server versions newer than 2.0 if the new value is less than 600 seconds. Values greater than or equal to 600 seconds will be ignored by mongod and mongos.
What tools are available for monitoring MongoDB?¶
The MongoDB Management Service includes monitoring functionality, which collects data from running MongoDB deployments and provides visualization and alerts based on that data.
Memory Diagnostics for the MMAPv1 Storage Engine¶
Do I need to configure swap space?¶
Always configure systems to have swap space. Without swap, your system may not be reliant in some situations with extreme memory constraints, memory leaks, or multiple programs using the same memory. Think of the swap space as something like a steam release valve that allows the system to release extra pressure without affecting the overall functioning of the system.
Nevertheless, systems running MongoDB do not need swap for routine operation. Database files are memory-mapped and should constitute most of your MongoDB memory use. Therefore, it is unlikely that mongod will ever use any swap space in normal operation. The operating system will release memory from the memory mapped files without needing swap and MongoDB can write data to the data files without needing the swap system.
What is a “working set”?¶
The working set is the portion of your data that clients access most often.
Must my working set size fit RAM?¶
Your working set should stay in memory to achieve good performance. Otherwise many random disk IO’s will occur, and unless you are using SSD, this can be quite slow.
One area to watch specifically in managing the size of your working set is index access patterns. If you are inserting into indexes at random locations (as would happen with id’s that are randomly generated by hashes), you will continually be updating the whole index. If instead you are able to create your id’s in approximately ascending order (for example, day concatenated with a random id), all the updates will occur at the right side of the b-tree and the working set size for index pages will be much smaller.
It is fine if databases and thus virtual size are much larger than RAM.
How do I calculate how much RAM I need for my application?¶
The amount of RAM you need depends on several factors, including but not limited to:
- The relationship between database storage and working set.
- The operating system’s cache strategy for LRU (Least Recently Used)
- The impact of journaling
- The number or rate of page faults and other MMS gauges to detect when you need more RAM
- Each database connection thread will need up to 1 MB of RAM.
MongoDB defers to the operating system when loading data into memory from disk. It simply memory maps all its data files and relies on the operating system to cache data. The OS typically evicts the least-recently-used data from RAM when it runs low on memory. For example if clients access indexes more frequently than documents, then indexes will more likely stay in RAM, but it depends on your particular usage.
To calculate how much RAM you need, you must calculate your working set size, or the portion of your data that clients use most often. This depends on your access patterns, what indexes you have, and the size of your documents. Because MongoDB uses a thread per connection model, each database connection also will need up to 1MB of RAM, whether active or idle.
If page faults are infrequent, your working set fits in RAM. If fault rates rise higher than that, you risk performance degradation. This is less critical with SSD drives than with spinning disks.
How do I read memory statistics in the UNIX top command¶
Because mongod uses memory-mapped files, the memory statistics in top require interpretation in a special way. On a large database, VSIZE (virtual bytes) tends to be the size of the entire database. If the mongod doesn’t have other processes running, RSIZE (resident bytes) is the total memory of the machine, as this counts file system cache contents.
For Linux systems, use the vmstat command to help determine how the system uses memory. On OS X systems use vm_stat.