What uses that much memory during the resync?
There is so many things uses the memory during the resync time, As
Mr. SpiXel has clearly defined here The WiredTiger cache settings only controls the size of memory directly used by the WiredTiger storage engine (not the total memory used by mongod). Many other things are potentially taking memory in a MongoDB/WiredTiger configuration, such as the following:
- WiredTiger compresses disk storage, but the data in memory are
- WiredTiger by default does not fsync the data on each commit
- WiredTiger keeps multiple versions of records in its cache
- WiredTiger Keeps checksums of the data in cache
- MongoDB itself consumes memory to handle open connections,
aggregations, serverside code and etc.
The maximum size of the internal cache that WiredTiger will use for all data.
Changed in version 3.4: Values can range from 256MB to 10TB and can be a float. In addition, the default value has also changed.
WiredTiger internal cache, by default, will use the larger of either:
50% of (RAM - 1 GB), or
For example, on a system with a total of 4GB of RAM the WiredTiger cache will use 1.5GB of RAM (0.5 * (4 GB - 1 GB) = 1.5 GB). Conversely, a system with a total of 1.25 GB of RAM will allocate 256 MB to the WiredTiger cache because that is more than half of the total RAM minus one gigabyte (0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).
How do I effectively analyze the memory consumption?
As per MongoDB blog here some of the by
@CASEY DUNHAM, MongoDB performance is a huge topic encompassing many areas of system activity.
By default, MongoDB will reserve
50 percent of the available memory for the WiredTiger data cache. The size of this cache is important to ensure WiredTiger performs adequately. It’s worth taking a look to see if you should alter it from the default. A good rule of thumb is that the size of the cache should be big enough to hold the entire application working set.
How do we know whether to alter it? Look at the cache usage statistics:
"tracked dirty bytes in the cache" : <num>,
"tracked bytes belonging to internal pages in the cache" : <num>,
"bytes currently in the cache" : <num>,
"tracked bytes belonging to leaf pages in the cache" : <num>,
"maximum bytes configured" : <num>,
"tracked bytes belonging to overflow pages in the cache" : <num>,
"bytes read into cache" : <num>,
"bytes written from cache" : <num>,
"pages evicted by application threads" : <num>,
"checkpoint blocked page eviction" : <num>,
"unmodified pages evicted" : <num>,
"page split during eviction deepened the tree" : <num>,
"modified pages evicted" : <num>,
"pages selected for eviction unable to be evicted" : <num>,
"pages evicted because they exceeded the in-memory maximum" : <num>,
"pages evicted because they had chains of deleted items" : <num>,
"failed eviction of pages that exceeded the in-memory maximum" : <num>,
"hazard pointer blocked page eviction" : <num>,
"internal pages evicted" : <num>,
"maximum page size at eviction" : <num>,
"eviction server candidate queue empty when topping up" : <num>,
"eviction server candidate queue not empty when topping up" : <num>,
"eviction server evicting pages" : <num>,
"eviction server populating queue, but not evicting pages" : <num>,
"eviction server unable to reach eviction goal" : <num>,
"internal pages split during eviction" : <num>,
"leaf pages split during eviction" : <num>,
"pages walked for eviction" : <num>,
"eviction worker thread evicting pages" : <num>,
"in-memory page splits" : <num>,
"in-memory page passed criteria to be split" : <num>,
"lookaside table insert calls" : <num>,
"lookaside table remove calls" : <num>,
"percentage overhead" : <num>,
"tracked dirty pages in the cache" : <num>,
"pages currently held in the cache" : <num>,
"pages read into cache" : <num>,
"pages read into cache requiring lookaside entries" : <num>,
"pages written from cache" : <num>,
"page written requiring lookaside records" : <num>,
"pages written requiring in-memory restoration" : <num>
There’s a lot of data here, but we can focus on the following fields:
- wiredTiger.cache.maximum bytes configured: This is the maximum cache
- wiredTiger.cache.bytes currently in the cache – This is the size of
the data currently in the cache. This should not be greater than the
maximum bytes configured.
- wiredTiger.cache.tracked dirty bytes in the cache – This is the size
of the dirty data in the cache. This value should be less than the
bytes currently in the cache value.
Looking at these values, we can determine if we need to up the size of the cache for our instance. Additionally, we can look at the wiredTiger.cache.bytes read into cache value for read-heavy applications. If this value is consistently high, increasing the cache size may improve overall read performance.
How do I prevent the primary from going down because of the resync?
As per MongoDB blog documentation here There might be a situation when primarily becomes inaccessible. When a primary does not communicate with the other members of the set for more than
10 seconds, an eligible secondary will hold an election to elect itself the new primary.
The first secondary to hold an election and receive a majority of the members’ votes becomes primary.
Although the timing varies, the
failover process generally completes within a minute. For instance, it may take
10-30 seconds for the members of a replica set to declare a primary inaccessible. One of the remaining secondaries holds an election to elect itself as a
new primary. The election itself may take another
While an election is in the process, the replica set has no primary and cannot accept writes and all remaining members become read-only.
For further your ref here , here and here