10

From the doc , it said

"For best performance, the majority of your active set should fit in RAM."

So for example, my db.stats() give me

{
"db" : "mydb",
"collections" : 16,
"objects" : 21452,
"avgObjSize" : 768.0516501957859,
"dataSize" : 16476244,
"storageSize" : 25385984,
"numExtents" : 43,
"indexes" : 70,
"indexSize" : 15450112,
"fileSize" : 469762048,
"ok" : 1
}

Which value is the working set size?

Howard
  • 2,005
  • 11
  • 47
  • 70
  • 2
    http://stackoverflow.com/questions/6453584/what-does-it-mean-to-fit-working-set-into-ram-for-mongodb – quanta Sep 10 '12 at 06:14

1 Answers1

10

The SO question/answer linked by quanta in the comments is correct, the "Working set" is basically the amount of data AND indexes that will be active/in use by your system.

You cannot tell from db.stats() what that will be unless you think that you will need to have the entire set of data and the entire index in RAM. That is, you can work out the maximum working set for that database, but not the actual active working set. The maximum is the sum of:

  1. dataSize - The total size of the data held in this database
  2. indexSize - The total size of all indexes created on this database

In your case, that maximum would be approximately 30.45 MiB given the output you pasted.

For tracking the actual memory usage I would recommend a combination of the figures from db.stats() and the memory graphs (resident memory in particular) available in the free monitoring tool - MMS.

Update (04/08/2013):

Version 2.4 added a Working Set Size Estimator to the serverStatus command - it is just an estimate, but it can be used as a guide and to check if the other figures and estimates above make sense for you MongoDB instance.

Update (September 2016):

Three years on from my original answer and things are a great deal more complicated - generally getting the size of your data and your indexes is stil a good starting point. But, figuring things out in MongoDB will now depend on what storage engine you are using. Additionally, Version 3.0 removed the Working Set estimator linked above for MMAP as part of the collection level locking work (see SERVER-13783). There is now (for example) the cache statistics for the WiredTiger engine as a replacement assuming you have made the jump to the new engine. For MMAP, the general recommendation is to look at the page faults metric as a proxy for whether your data is fitting into memory or not.

Community
  • 1
Adam C
  • 5,132
  • 2
  • 28
  • 49
  • Actually I am using `MMS` already, but I am not sure what figure to look at. – Howard Sep 10 '12 at 16:44
  • Generally the resident figure on the memory graph is the most relevant here. It will grow over time and occupy all available RAM (with older data paged out as needed for new data to be paged in) if your data set is significantly larger than RAM. If not and the data set is fairly static, it will find a lower level and hover there. The Max value I outline above would be the most RAM an individual database would take up as part of that figure. – Adam C Sep 10 '12 at 16:53
  • 1
    The serverStatus command no longer includes the working set size estimation, as of MongoDB 3.0. https://docs.mongodb.com/manual/reference/command/serverStatus/ – Vince Bowdren Sep 05 '16 at 11:02
  • 1
    Things have changed a lot in 3-4 years. I have left the original and added an udpate to cover some of the options in the newer versions. – Adam C Sep 05 '16 at 11:37