La pregunta / respuesta SO vinculada por cuantos en los comentarios es correcta, el "conjunto de trabajo" es básicamente la cantidad de datos e índices que estará activo / en uso por su sistema.
No puede saber de db.stats()qué se trata, a menos que piense que necesitará tener todo el conjunto de datos y todo el índice en la RAM. Es decir, puede calcular el conjunto de trabajo máximo para esa base de datos, pero no el conjunto de trabajo activo real. El máximo es la suma de:
- dataSize : el tamaño total de los datos contenidos en esta base de datos
- indexSize : el tamaño total de todos los índices creados en esta base de datos
En su caso, ese máximo sería aproximadamente 30.45 MiB dada la salida que pegó.
Para realizar un seguimiento del uso real de la memoria, recomendaría una combinación de las cifras db.stats()y los gráficos de memoria (memoria residente en particular) disponibles en la herramienta de monitoreo gratuita: MMS .
Actualización (04/08/2013):
La versión 2.4 agregó un Estimador de tamaño de conjunto de trabajo al comando serverStatus : es solo una estimación, pero se puede usar como guía y para verificar si las otras cifras y estimaciones anteriores tienen sentido para su instancia de MongoDB.
Actualización (septiembre de 2016):
Tres años después de mi respuesta original y las cosas son mucho más complicadas, generalmente obtener el tamaño de sus datos y sus índices todavía es un buen punto de partida. Pero, resolver las cosas en MongoDB ahora dependerá del motor de almacenamiento que esté utilizando. Además, la versión 3.0 eliminó el estimador del conjunto de trabajo vinculado anteriormente para MMAP como parte del trabajo de bloqueo de nivel de recopilación (consulte SERVER-13783 ). Ahora hay (por ejemplo) las estadísticas de caché para el WiredTigermotor como reemplazo, suponiendo que haya hecho el salto al nuevo motor. Para MMAP, la recomendación general es mirar la métrica de fallas de la página como un proxy para determinar si sus datos se ajustan a la memoria o no.