Comment obtenir la taille actuelle du jeu de travail de MongoDB

Du doc , il a dit

"Pour de meilleures performances, la majorité de votre ensemble actif doit tenir dans la RAM."

Ainsi, par exemple, mon db.stats()donnez-moi

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

Quelle est la valeur working set size?

mongodb nosql

— Howard
source

stackoverflow.com/questions/6453584/…

— quanta

La question / réponse SO liée par quanta dans les commentaires est correcte, le "Working set" est fondamentalement la quantité de données ET d'index qui seront actifs / utilisés par votre système.

Vous ne pouvez pas dire db.stats()ce que ce sera, sauf si vous pensez que vous aurez besoin d'avoir l'ensemble complet de données et l'index entier dans la RAM. Autrement dit, vous pouvez déterminer l'ensemble de travail maximal pour cette base de données, mais pas l'ensemble de travail actif réel. Le maximum est la somme de:

dataSize - La taille totale des données contenues dans cette base de données
indexSize - La taille totale de tous les index créés sur cette base de données

Dans votre cas, ce maximum serait d'environ 30,45 Mio compte tenu de la sortie que vous avez collée.

Pour suivre l'utilisation réelle de la mémoire, je recommanderais une combinaison des chiffres de db.stats()et des graphiques de mémoire (mémoire résidente en particulier) disponibles dans l'outil de surveillance gratuit - MMS .

Mise à jour (04/08/2013):

La version 2.4 a ajouté un estimateur de la taille du jeu de travail à la commande serverStatus - ce n'est qu'une estimation, mais il peut être utilisé comme guide et pour vérifier si les autres chiffres et estimations ci-dessus sont pertinents pour votre instance MongoDB.

Mise à jour (septembre 2016):

Trois ans après ma réponse d'origine et les choses sont beaucoup plus compliquées - obtenir généralement la taille de vos données et de vos index est un bon point de départ. Mais, comprendre les choses dans MongoDB dépendra désormais du moteur de stockage que vous utilisez. De plus, la version 3.0 a supprimé l'estimateur d'ensemble de travail lié ci-dessus pour MMAP dans le cadre du travail de verrouillage au niveau de la collection (voir SERVER-13783 ). Il y a maintenant (par exemple) les statistiques de cache pour le WiredTigermoteur en remplacement en supposant que vous avez fait le saut vers le nouveau moteur. Pour MMAP, la recommandation générale est de regarder la métrique des défauts de page comme un proxy pour savoir si vos données sont en mémoire ou non.

— Adam C
source

En fait, j'utilise MMSdéjà, mais je ne sais pas quel chiffre regarder.

— Howard

Généralement, le chiffre résident sur le graphique de la mémoire est le plus pertinent ici. Il augmentera au fil du temps et occupera toute la RAM disponible (avec des données plus anciennes paginées au besoin pour que de nouvelles données soient paginées) si votre ensemble de données est considérablement plus grand que la RAM. Sinon et l'ensemble de données est assez statique, il trouvera un niveau inférieur et y planera. La valeur maximale que je décris ci-dessus serait le plus de RAM qu'une base de données individuelle prendrait dans le cadre de ce chiffre.

— Adam C

La commande serverStatus n'inclut plus l'estimation de la taille de l'ensemble de travail, à partir de MongoDB 3.0. docs.mongodb.com/manual/reference/command/serverStatus

— Vince Bowdren

Les choses ont beaucoup changé en 3-4 ans. J'ai laissé l'original et ajouté une mise à jour pour couvrir certaines des options des nouvelles versions.

— Adam C