MongoDB: exigences RAM


20

Est-ce suffisant d'avoir tout l'index en mémoire / ram ou mongodb essaie-t-il même d'allouer autant de RAM que possible pour stocker même les données pour des lectures rapides?

Je voudrais exécuter mongodb + d'autres applications et il semble que mongodb soit le seul qui ne me permette pas de définir une plage de RAM, pour dire "max_memory_allocated_or_reserved = 8GB".

S'il n'y a aucun moyen de le faire, je devrais expliquer à oom-killer que mongod est le "mauvais" processus qui n'est pas la meilleure pratique à mon avis ...

Réponses:


18

La vraie raison pour laquelle vous ne pouvez pas faire ce que vous demandez (limiter la mémoire) est que MongoDB ne gère pas directement la mémoire qu'il utilise - il laisse le système d'exploitation le faire. MongoDB se contente de mapper toutes ses données sur la mémoire, puis a la page du système d'exploitation dans et hors de la mémoire selon les besoins. En conséquence, il n'y a pas de gestion directe de la quantité utilisée possible jusqu'à ce que MongoDB implémente cela d'une manière complètement différente, ou que le système d'exploitation le permette (pas possible sous Linux depuis les 2,4 jours).

À l'heure actuelle, la seule façon de vraiment séparer les ressources est d'utiliser une solution de virtualisation et d'isoler MongoDB dans sa propre machine virtuelle. Oui, il y a des frais généraux impliqués (bien que les hyperviseurs se soient beaucoup améliorés), mais pour le moment, c'est le prix à payer pour ce niveau de contrôle des ressources.

En ce qui concerne OOM Killer, même sans aucun autre processus sur l'hôte, tant que votre ensemble de données et vos index dépassent globalement la mémoire disponible, MongoDB peut rencontrer des problèmes OOM Killer. Cela est dû à la façon dont les données sont paginées hors de la mémoire - s'il n'y a pas de pression de mémoire (rien d'autre ne veut de mémoire résidente), et que vous continuez à ajouter / toucher de nouvelles données et index, puis finalement elles augmenteront pour consommer toute la RAM disponible. D'où la recommandation de toujours configurer un swap lors de l'exécution de MongoDB:

https://docs.mongodb.com/manual/administration/production-notes/#swap

Bien sûr, les données LRU seront paginées en premier, d'autres processus peuvent également prendre la res mem, mais le concept s'applique toujours, sauf si vous chargez votre ensemble de données en mémoire et qu'il reste statique. La meilleure chose à faire si vous êtes inquiet est de l'intégrer dans MMS et de suivre l'utilisation au fil du temps:

http://mms.mongodb.com

Mise à jour: août 2015

Depuis que j'ai écrit cette réponse, les choses ont quelque peu évolué et les informations sont un peu dépassées. Par exemple, Linux dispose désormais de groupes de contrôle et de technologies connexes ( conteneurs Docker par exemple) qui sont arrivés à maturité au point de vous permettre de mieux isoler et limiter les ressources ( y compris la mémoire ) consommées par n'importe quel processus dans un environnement de production, même celui qui utilise mappage de mémoire comme MongoDB.

De plus, avec l'avènement de nouveaux moteurs de stockage au-delà de MMAP comme WiredTiger dans MongoDB 3.0+, vous pouvez utiliser la fonctionnalité intégrée pour limiter la taille du cache pour MongoDB. Par conséquent, les exigences de RAM dépendent désormais vraiment de la façon dont vous choisissez de configurer MongoDB, de l'environnement dans lequel vous l'exécutez et du moteur de stockage que vous choisissez.


concernant WiredTiger: " Le stockage.wiredTiger.engineConfig.cacheSizeGB ne limite que la taille du cache WiredTiger, pas la quantité totale de mémoire utilisée par mongod. Le cache WiredTiger n'est qu'un composant de la RAM utilisée par MongoDB. MongoDB utilise également automatiquement tous les mémoire libre sur la machine via le cache du système de fichiers ... "
Stefan Rogin

à droite, mais la même chose peut être dite de toute application qui pages des données hors disque, le cache FS n'est plus la méthode de mise en cache principale pour les données comme c'était le cas avec les fichiers mappés en mémoire dans le moteur de stockage MMAP
Adam C

6

MongoDB utilisera la mémoire libre disponible pour la mise en cache et échangera sur le disque si nécessaire pour fournir de la mémoire à d'autres applications sur le même serveur. Pour de meilleures performances, vous voudrez disposer de suffisamment de RAM pour conserver en mémoire vos index et les données fréquemment utilisées ("working set").

Lecture utile:


3

Quelque chose a changé au fil des ans à propos de MongoDB.

TL; DR

Si le moteur de stockage MMAPv1 est utilisé sur la working settaille MongoDB, la mémoire RAM doit être adaptée . https://docs.mongodb.com/manual/faq/diagnostics/#must-my-working-set-size-fit-ram

Si le moteur de stockage WiredTiger est utilisé sur MongoDB, pas besoin de préoccupation au sujet de RAM est apte à working setou non . https://docs.mongodb.com/manual/faq/diagnostics/#memory-diagnostics-for-the-wiredtiger-storage-engine

Diagnostics de mémoire pour le moteur de stockage WiredTiger

La taille de mon ensemble de travail doit-elle s'adapter à la RAM?

Non.

Comment calculer la quantité de RAM dont j'ai besoin pour mon application?

Avec WiredTiger, MongoDB utilise à la fois le cache interne WiredTiger et le cache du système de fichiers.

Modifié dans la version 3.2: à partir de MongoDB 3.2, le cache interne de WiredTiger, par défaut, utilisera le plus grand des deux:

60% de RAM moins 1 Go, ou 1 Go.


eh bien cette réponse n'est pas très utile, ni terriblement précise.
Philip Schiff
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.