CODEWITHSUNDEEP
mongodbmemory-management
Roelof Spijker
Roelof Spijker

Reputation: 173

Why is MongoDB's local database almost completely in memory?

I have a replicated mongodb setup and I am seeing a lot of page faults. So I started to investigate and found out (through vmmap) that almost the entire local database is in memory (that is, part of the working set). The only collection of significance there is of course the oplog.rs which is used for replication. Looking at the queries being run, the ones on the oplog are for data that is a lot closer to the tail than to the head of the oplog. So why is the entire thing still in memory? Surely it should be swapped out due to the large amount of faults.

Am I misunderstanding something here? Am I reading the vmmap information incorrectly? Or is something actually going wrong?

VMMap screenshot

Note that this is a testing setup and there are some other mongod instances running on this hardware, therefore the total amount of memory used here does not sum up to the total in the machine. Overall, the memory usage is ~100% though.

Upvotes: 6

Views: 754

Answers (1)

Chris Heald
Chris Heald

Reputation: 62688

Mongo delegates page management to the kernel - since it uses mapped files, it just relies on the kernel to decide what to page out. Your local database is being touched every time you do a write, or receive a read from another. The oplog is a capped collection, so it's going to be constantly modifying a fixed space in the data files (and thus, a fixed space in RAM), which should keep it touched and not very high on the priority list for being paged out.

As to your high number of page faults, is it possible that those are simple cache warming? Mongo isn't going to load its working set into memory when it's freshly started, so it'll take a bit of querying for things to warm up and get stuff off of disk and into memory.

Don't forget to account for caches and buffers - your memory usage might be reading at 100%, but the kernel is going to expire caches and buffers before it pages out other things, so it might be that while your system is reporting close to 100% usage, a significant chunk of that is caches and buffers that'll be flushed as needed, meaning that mongo's working set never has to be paged out at all.

You might be able to test this by running a program designed to eat more and more memory (like this one) and see how mongo behaves once your system is actually hitting swap.

Upvotes: 4

Related Questions