Article Directory
One, MongoDB memory usage overview
MongoDB memory consumption mainly has two parts:
1、存储引擎
2、client建立的连接的请求处理
1.1 The memory consumption of the storage engine
After MongoDB version 3.2, the default storage engine is wiredtiger. The wiredtiger storage engine can be controlled by cacheSizeGB. Generally, it is recommended that this parameter be set to 60% of the system's available memory.
MongoDB uses Google tcmalloc as a memory allocator. When the memory is close to a certain threshold, it will start to eliminate it to avoid blocking user requests when the memory is full.
Tcmalloc memory elimination mechanism:
| parameter | Defaults | meaning |
|---|---|---|
| eviction_target | 80 | When cache used exceeds eviction_target, the background evict thread starts to eliminate CLEAN PAGE |
| eviction_trigger | 95 | When cache used exceeds eviction_trigger, user threads also start to eliminate CLEAN PAGE |
| eviction_dirty_target | 5 | When cache dirty exceeds eviction_dirty_target, the background evict thread starts to eliminate DIRTY PAGE |
| eviction_dirty_trigger | 20 | When cache dirty exceeds eviction_dirty_trigger, user threads also start to eliminate DIRTY PAGE |
Under this rule, the memory usage of a normally running mongodb instance is about 0.8 of cacheSizeGB, and occasionally exceeding it is not a problem.
If used>90% or dirty>20% continue to appear, it means that the memory elimination pressure is very high, and the user's request thread will be blocked to participate in the page elimination, and the request delay will increase. At this time, you can consider [Increase memory] or [Replace a disk with stronger IO capabilities]
1.2 TCP connection and request processing
1. TCP protocol stack
Socket metadata, read buffer\write buffer of each thread, and
the size of the user's sending and receiving network packet buffer are configured through the following sysctl system parameters
2. Request thread stack
MongoDB creates a separate thread for each connection.
mongod configures a thread stack of up to 1MB for the thread that handles connection requests, usually around tens of KB.
The actual overhead of these thread stacks can be seen through the proc file system.
3. Background thread stack
Main and standby synchronization, periodic refresh of Journal, TTL, evict and other threads The
default maximum ulimit -s (usually 10MB) thread stack for each thread
4. How does the MongoDB client create a connection to consume memory?
1) Each thread will have its own local free page cache, as well as a central free page cache
2) When applying for memory, it will first query the available memory from the local free page cache, if it does not continue to look for the available memory in the central free page cache
3 ) If you still can’t find the available memory above, then go to the heap to apply for memory.
4) When the memory is released, the memory will be returned to the cache first, and tcmalloc will be returned to the OS slowly.
2. How to control the memory usage of MongoDB
2.1 Reasonable configuration of cacheSizeGB
Set the memory limit reasonably through the cacheSizeGB parameter and the actual server RAM configuration. Generally, it is recommended to set the cacheSizeGB parameter to 60% of the available memory. Of course, we also need to consider whether there are other services that consume a lot of memory on the current server.
2.2 Control the number of concurrent connections
-
The application-level
MongoDB driver maintains a connection pool (usually 100 by default) when connecting to mongod. When a large number of clients access the same mongod at the same time, you need to consider reducing the size of each client's connection pool -
At the database level,
use net.maxIncomingConnections to limit the number of concurrent MongoDB connections to prevent database overload.
Concurrent connection control from the database level is our last line of defense. More importantly, we need to further analyze whether the large number of concurrent requests is the real business pressure is too large, or the query execution efficiency is too low to cause the session backlog.
2.3 Configure swap
If swap is configured, it can effectively prevent the MongoDB service from OOM, but when the memory is insufficient, frequent use of swap will seriously affect the database performance.
The optimal scenario is to configure sufficient memory for the MongoDB service, and if the memory is insufficient, expand the capacity in time
2.4 Other
1) Minimize the scene of memory sorting. Memory sorting generally requires more temporary memory.
2) The configuration gap between the active and standby nodes should not be too large. The standby node will maintain a buffer (default maximum 256MB) for storage and pull to oplog. The oplog in the buffer is continuously replayed. When the backup synchronization is slow, the buffer will continue to use the maximum memory.
3) Control the number of collections and indexes to reduce the memory overhead of databse to manage metadata; too many collections and indexes, metadata memory overhead is an impact on the one hand, and more will affect the efficiency of startup loading and runtime performance.
Reference document:
https://yq.aliyun.com/articles/685044?spm=a2c4e.11155435.0.0.155a135eYaJeyU