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.
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:
la source
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-ramSi 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-enginela source