serverStatus.workingSet.pagesInMemory
pagesInMemory contains a count of the total number of pages accessed by mongod over the period displayed in overSeconds. The default page size is 4 kilobytes: to convert this value to the amount of data in memory multiply this value by 4 kilobytes.
If your total working set is less than the size of physical memory, over time the value of pagesInMemory will reflect your data size. Conversely, if your data set is greater than the size of the physical RAM, this number will reflect the total size of physical RAM.
Use pagesInMemory in conjunction with overSeconds to help estimate the actual size of the working set.
Also, there's a discussion of working set in this guide starting on page 9: http://info.10gen.com/rs/10gen/images/10gen-MongoDB_Operatio...
This is called capacity planning. If you can't estimate what resources you use, I wouldn't expect great success scaling.
I didn't realize this is the first MongoDB release for which you can even reasonably do capacity planning. How did people plan before if there were no metrics?