Understanding memory utilization in RavenDB

time to read 2 min | 369 words

This is a snapshot from our production server right his moment. As you can see, the system is now using every little bit of RAM that it has at its disposal. You can also see that the CPU is kinda busy and the network is quite active.


In most cases, an admin seeing this will immediately hit the alarm bell and start figuring out what is causing the system to use all available memory. This looks like a system that is in the precipice of doom, after all.

However, this is a system that is actually:

  • Working as intended
  • Is quite fast
  • Have plenty of extra head room to spare

The problem is that the numbers, as you see them here, are lying to you. The system is using 3.9 GB of memory, but look at the value of the Committed. There are only 2.6GB that are actually committed. Memory internals are complex, but basically, this means that the system need to find place in RAM and on the page file for a 2.6GB. But what about all the other stuff? That is being used, but it isn’t held back from the system if we need it. RavenDB is making active use of all the memory that is available in the system, by way of memory mapped files. Let’s see what the RAMMap tool (which is great is diagnosing such issues) tells us:


So out of a total of 4GB on this machine, about 2.5 GB that are actually in memory are memory mapped files. Out of which we have 1.3 GB in the active set (so they are actively worked on), but we also have 1.1GB here that are in the Standby column.

What this means is that this is memory that is the OS can just repurpose without any extra costs attached. Note that the amount of modified memory (which will require us to write it out to disk) is really small.

This is a good place to be at, even if at first glace it was quite surprising to see.