Cómo obtener el tamaño de conjunto de trabajo actual de MongoDB

9

Desde el documento , decía

"Para un mejor rendimiento, la mayoría de su conjunto activo debe caber en la RAM".

Entonces, por ejemplo, mi db.stats()dame

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

¿Qué valor es el working set size?

mongodb nosql Howard
fuente
2
stackoverflow.com/questions/6453584/…
cuantos

Respuestas:

9

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:

  1. dataSize : el tamaño total de los datos contenidos en esta base de datos
  2. 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.

Adam C
fuente
En realidad ya estoy usando MMS, pero no estoy seguro de qué figura mirar.
Howard
En general, la figura residente en el gráfico de memoria es la más relevante aquí. Crecerá con el tiempo y ocupará toda la RAM disponible (con los datos más antiguos eliminados según sea necesario para que los nuevos datos sean paginados) si su conjunto de datos es significativamente mayor que la RAM. Si no es así y el conjunto de datos es bastante estático, encontrará un nivel inferior y se desplazará allí. El valor máximo que describo arriba sería la mayor cantidad de RAM que una base de datos individual tomaría como parte de esa cifra.
Adam C
1
El comando serverStatus ya no incluye la estimación del tamaño del conjunto de trabajo, a partir de MongoDB 3.0. docs.mongodb.com/manual/reference/command/serverStatus
Vince Bowdren
1
Las cosas han cambiado mucho en 3-4 años. Dejé el original y agregué una udpate para cubrir algunas de las opciones en las versiones más recientes.
Adam C