2

We are facing the issue with mongodb that is cpu is always 100% and the memory usage gradually reaches 100% too.

On analyzing the stats of a collection we found out that the caching is having huge dirty cache.

 "cache" : {
            "bytes currently in the cache" : 2138193726.0,
            "bytes dirty in the cache cumulative" : 26878586216.0,
            "bytes read into cache" : 2684641105.0,
            "bytes written from cache" : 9250929218.0,
            "checkpoint blocked page eviction" : 0,
            "data source pages selected for eviction unable to be evicted" : 1,
            "eviction walk passes of a file" : 1373,
            "eviction walk target pages histogram - 0-9" : 24,
            "eviction walk target pages histogram - 10-31" : 117,
            "eviction walk target pages histogram - 128 and higher" : 0,
            "eviction walk target pages histogram - 32-63" : 1084,
            "eviction walk target pages histogram - 64-128" : 148,
            "eviction walks abandoned" : 636,
            "eviction walks gave up because they restarted their walk twice" : 0,
            "eviction walks gave up because they saw too many pages and found no candidates" : 3,
            "eviction walks gave up because they saw too many pages and found too few candidates" : 2,
            "eviction walks reached end of tree" : 236,
            "eviction walks started from root of tree" : 641,
            "eviction walks started from saved location in tree" : 732,
            "hazard pointer blocked page eviction" : 1,
            "in-memory page passed criteria to be split" : 0,
            "in-memory page splits" : 0,
            "internal pages evicted" : 1,
            "internal pages split during eviction" : 0,
            "leaf pages split during eviction" : 7,
            "modified pages evicted" : 9826,
            "overflow pages read into cache" : 0,
            "page split during eviction deepened the tree" : 0,
            "page written requiring cache overflow records" : 0,
            "pages read into cache" : 121604,
            "pages read into cache after truncate" : 0,
            "pages read into cache after truncate in prepare state" : 0,
            "pages read into cache requiring cache overflow entries" : 0,
            "pages requested from the cache" : 380045669,
            "pages seen by eviction walk" : 101851,
            "pages written from cache" : 559839,
            "pages written requiring in-memory restoration" : 0,
            "tracked dirty bytes in the cache" : 47012214,
            "unmodified pages evicted" : 36225
        },

Is this which is causing memory problems in mongodb and what are the possible ways by which we can imporve memoory management of the db

nopassport1
  • 1,821
  • 1
  • 25
  • 53
Raj Saraogi
  • 1,780
  • 1
  • 13
  • 21
  • `dirty bytes` refers to modified/inserted documents. If you have a large number of this, it generally means the server cannot write them out to disk fast enough, so more work will pile up on top of them. If you find that your hardware keep getting maxed out, it's probably time to invest in better hardware, e.g. larger RAM, faster disk, etc. – kevinadi Jan 13 '20 at 22:04
  • Hey @kevinadi dirty bytes track is almost 10 times less then the bytes used, but the "bytes dirty in the cache cumulative" is really huge, so which metric should we consider among this? – Raj Saraogi Jan 16 '20 at 11:56

0 Answers0