It uses memory mapped files, which is different from malloc()ing a whole lot of memory. If you do a "top" or whatever, it won't show up as taking a lot of resid

It uses memory mapped files, which is different from malloc()ing a whole lot of memory. If you do a "top" or whatever, it won't show up as taking a lot of resident memory, but "free" will show it being taken up in the "cached" column. The end result is that it will "use" all available memory on the system, but if you want to run anything else alongside, the kernel will just de-allocate memory from MongoDB and allocate it to other processes. The only downside is that it's not very tuneable -- you are at the mercy of the kernel and its algorithms. In my experience if you have enough memory to hold your "working set" (which has a fairly loose definition), you should be fine. We have also disabled swap on our servers -- I would recommend trying it, but do so carefully, you don't want your database server being OOM'd while serving production traffic. We have 2 DB servers each with 24GB RAM and the whole database is about 90GB but that includes a bunch of logging stuff that is truncated periodically and it's not in our "working set". We are running other processes on the DB servers as well (the ones I mentioned) and everything is running fine.