Traemos la mejor respuesta que hallamos online. Esperamos que te resulte de mucha utilidad y si deseas comentarnos cualquier detalle que nos pueda ayudar a mejorar puedes hacerlo..
Solución:
La verdadera razón por la que no puede hacer lo que pide (limitar la memoria) es porque MongoDB no administra la memoria que usa directamente, deja que el sistema operativo lo haga. MongoDB solo mapea en la memoria todos sus datos y luego hace que el sistema operativo los introduzca y saque de la memoria según sea necesario. Como resultado, no es posible una gestión directa de la cantidad utilizada hasta que MongoDB implemente esto de una manera completamente diferente, o el sistema operativo lo permita (no es posible en Linux desde los 2.4 días).
Actualmente, la única forma de segregar realmente los recursos es usar una solución de virtualización y aislar MongoDB en su propia máquina virtual. Sí, hay gastos generales involucrados (aunque los hipervisores han mejorado mucho), pero en este momento ese es el precio a pagar por ese nivel de control de recursos.
En términos de OOM Killer, incluso sin otros procesos en el host, siempre que su conjunto de datos e índices en general excedan la memoria disponible, MongoDB puede tener problemas con OOM Killer. Esto se debe a cómo los datos se paginan fuera de la memoria: si no hay presión de memoria (nada más quiere memoria residente) y sigue agregando/tocando nuevos datos e índices, eventualmente crecerá para consumir toda la RAM disponible. De ahí la recomendación de configurar siempre algún intercambio cuando se ejecuta MongoDB:
https://docs.mongodb.com/manual/administration/production-notes/#swap
Por supuesto, los datos LRU se paginarán primero, otros procesos también pueden ocupar la memoria res, pero el concepto aún se aplica a menos que cargue su conjunto de datos en la memoria y luego permanezca static. Lo mejor que puede hacer si está preocupado es ingresarlo en MMS y realizar un seguimiento del uso a lo largo del tiempo:
http://mms.mongodb.com
Actualización: agosto de 2015
Desde que escribí esta respuesta, las cosas han avanzado un poco y la información está un poco desactualizada. Por ejemplo, Linux ahora tiene cgroups y tecnologías relacionadas (por ejemplo, contenedores Docker) que han madurado hasta el punto de permitirle aislar y limitar mejor los recursos (incluida la memoria) consumidos por cualquier proceso en un entorno de producción, incluso uno que utiliza mapeo de memoria como MongoDB.
Además, con la llegada de nuevos motores de almacenamiento más allá de MMAP como WiredTiger en MongoDB 3.0+, puede usar la funcionalidad integrada para limitar el tamaño de caché para MongoDB. Por lo tanto, los requisitos de RAM ahora realmente dependen de cómo elija configurar MongoDB, en qué entorno lo ejecute y qué motor de almacenamiento elija.
MongoDB utilizará la memoria libre disponible para el almacenamiento en caché y se intercambiará en el disco según sea necesario para proporcionar memoria a otras aplicaciones en el mismo servidor. Para obtener el mejor rendimiento, querrá tener suficiente RAM para mantener sus índices y datos de uso frecuente (“conjunto de trabajo”) en la memoria.
Lectura útil:
- Preguntas frecuentes de MongoDB: ¿MongoDB requiere mucha RAM?
- MongoDB Wiki: Comprobación del uso de la memoria del servidor
Algunas cosas han cambiado en años sobre MongoDB.
TL;DR
Si se utiliza el motor de almacenamiento MMAPv1 en MongoDB working set el tamaño debe caber RAM. https://docs.mongodb.com/manual/faq/diagnostics/#must-my-working-set-size-fit-ram
Si se utiliza el motor de almacenamiento WiredTiger en MongoDB, no hay necesidad de preocuparse por la memoria RAM es apto para working set O no. https://docs.mongodb.com/manual/faq/diagnostics/#memory-diagnostics-for-the-wiredtiger-storage-engine
Diagnóstico de memoria para el motor de almacenamiento WiredTiger
¿El tamaño de mi conjunto de trabajo debe ajustarse a la RAM?
No.
¿Cómo calculo cuánta RAM necesito para mi aplicación?
Con WiredTiger, MongoDB utiliza tanto la caché interna de WiredTiger como la caché del sistema de archivos.
Modificado en la versión 3.2: a partir de MongoDB 3.2, la memoria caché interna de WiredTiger, de forma predeterminada, utilizará el mayor de los siguientes:
60% de RAM menos 1 GB, o 1 GB.