'How do I configure the cache size for Mongodb?
I need to handle cashing in Mongodb.Does It requires a lot of RAM for doing that? What are the specialties and advantages using storage engines in this case?
Solution 1:[1]
Method (does not survive a restart):
./bin/mongo admin
db.adminCommand( { "setParameter": 1, "wiredTigerEngineRuntimeConfig": "cache_size=10G"})
start mongodb serve with
./bin/mongod --config server.conf --wiredTigerCacheSizeGB=10
--- server.conf (one key/value per line) ---
maxConns=200
logpath=logs/server.log
logappend=true
fork=true
dbpath=data
nohttpinterface=true
syncdelay=60
quiet = true
slowms = 2000
notablescan = false
Check size with this command:
> db.serverStatus().wiredTiger.cache
{
"bytes currently in the cache" : 4606522365,
"bytes read into cache" : 3291056,
"bytes written from cache" : 5631783282,
"checkpoint blocked page eviction" : 0,
"eviction currently operating in aggressive mode" : 0,
"eviction server candidate queue empty when topping up" : 448,
"eviction server candidate queue not empty when topping up" : 0,
"eviction server evicting pages" : 0,
"eviction server populating queue, but not evicting pages" : 447,
"eviction server unable to reach eviction goal" : 0,
"eviction worker thread evicting pages" : 12,
"failed eviction of pages that exceeded the in-memory maximum" : 0,
"files with active eviction walks" : 0,
"files with new eviction walks started" : 105,
"hazard pointer blocked page eviction" : 0,
"in-memory page passed criteria to be split" : 896,
"in-memory page splits" : 448,
"internal pages evicted" : 0,
"internal pages split during eviction" : 0,
"leaf pages split during eviction" : 13,
"lookaside table insert calls" : 0,
"lookaside table remove calls" : 0,
"maximum bytes configured" : 10737418240, <---- this is the configured size
"maximum page size at eviction" : 8388576,
"modified pages evicted" : 13,
"modified pages evicted by application threads" : 0,
"page split during eviction deepened the tree" : 0,
"page written requiring lookaside records" : 0,
"pages currently held in the cache" : 675,
"pages evicted because they exceeded the in-memory maximum" : 1,
"pages evicted because they had chains of deleted items" : 448,
"pages evicted by application threads" : 0,
"pages queued for eviction" : 12,
"pages queued for urgent eviction" : 0,
"pages read into cache" : 234,
"pages read into cache requiring lookaside entries" : 0,
"pages seen by eviction walk" : 25702,
"pages selected for eviction unable to be evicted" : 0,
"pages walked for eviction" : 127975,
"pages written from cache" : 310352,
"pages written requiring in-memory restoration" : 0,
"percentage overhead" : 8,
"tracked bytes belonging to internal pages in the cache" : 316858,
"tracked bytes belonging to leaf pages in the cache" : 4606205507,
"tracked bytes belonging to overflow pages in the cache" : 0,
"tracked dirty bytes in the cache" : 809239633,
"tracked dirty pages in the cache" : 190,
"unmodified pages evicted" : 0
}
Solution 2:[2]
A more concise output of the WT cache size in GB would be :
db.serverStatus().wiredTiger.cache["maximum bytes configured"]/1024/1024/1024 64
Solution 3:[3]
Dba is the appropriate place. Caching is already defined if you are using WiredTiger, using all RAM available, with dynamic provisioning.
Solution 4:[4]
I had the same problem, and I got the answer. Take a look at this answer.
I hope your problem is solved too.
Summary answer :)
You need to add these configurations to docker-campus configurations:
.......
deploy:
resources:
limits:
memory: 3G
reservations:
memory: 1G
command: --wiredTigerCacheSizeGB 0.25
.......
Sources
This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.
Source: Stack Overflow
| Solution | Source |
|---|---|
| Solution 1 | Literadix |
| Solution 2 | Alex Man |
| Solution 3 | Ricardo Barros Lourenço |
| Solution 4 | torham |
