MongoDB
Explica cómo el working set, la caché de WiredTiger y la memoria del sistema afectan latencia, page faults y estabilidad bajo cargas reales.
El es la parte de documentos e índices que el workload necesita con frecuencia. No toda la base debe caber en RAM, pero las páginas críticas deberían permanecer en memoria si la aplicación exige latencia estable.
query frecuente
→ páginas de índice
→ documentos calientes
→ WiredTiger cache + OS cacheCuando el working set supera la memoria útil, aumentan evictions y lecturas de disco; la latencia se vuelve más alta y variable.
WiredTiger administra su propia cache para páginas descomprimidas, updates y metadata. El sistema operativo también utiliza memoria para cachear archivos.
Por eso ver RAM casi llena no significa automáticamente problema. La pregunta es si existe presión:
Un índice completo puede medir cientos de GB, pero una query por tenant quizá use solo una pequeña zona. El tamaño total no explica por sí solo la memoria requerida.
Cada índice compite por cache. Un índice redundante no solo ocupa disco: sus páginas activas desplazan otras estructuras.
Analiza:
Eliminar un índice sin uso puede mejorar memoria, pero debe probarse mediante hidden index y una ventana representativa.
Si una query necesita un campo pequeño dentro de documentos enormes, FETCH carga más datos de los necesarios. Opciones:
No normalices todo por reflejo; mide el patrón real.
Ocurre cuando diferentes workloads expulsan continuamente páginas:
reporte escanea meses históricos
→ expulsa índices calientes
→ tráfico web vuelve a leer discoMitigaciones:
WiredTiger debe liberar páginas para mantener la cache dentro de límites. Eviction normal es esperada; el problema es cuando threads de aplicación ayudan constantemente o la tasa supera la capacidad.
Correlaciona eviction con:
Writes generan páginas dirty que deben persistirse. Si crecen demasiado, aumenta presión de checkpoint y eviction.
Causas:
Reducir write concern no corrige un disco insuficiente.
Transacciones o readers largos pueden obligar a conservar versiones antiguas. Esto aumenta memoria y storage pressure.
Evita:
MongoDB con swapping intenso suele sufrir latencia impredecible. Configura el host según recomendaciones de la versión y monitorea swap in/out, no solo capacidad asignada.
En containers, los límites de memoria deben incluir overhead del proceso y OS. Un límite demasiado bajo puede producir OOMKill aunque el host tenga RAM disponible.
Benchmarks deben distinguir:
Una query rápida solo en cache caliente puede fallar después de failover o scaling. Una query rápida solo por dataset pequeño no prueba producción.
En SaaS, un negocio puede concentrar datos y tráfico. Mide working set por tenant o partición cuando sea posible. Promedios pueden ocultar que un tenant desplaza a todos los demás.
Opciones:
Proyecta memoria desde:
Mantén margen para perder un nodo o ejecutar maintenance. Un cluster estable al 95 % de memoria útil puede no tener capacidad operativa.
El working set es dinámico y depende del workload, no del tamaño total de la base. WiredTiger y el OS usan memoria deliberadamente. Diagnostica presión mediante eviction, I/O y latencia; luego corrige query shapes, documentos e índices antes de añadir hardware sin análisis.
Storage engine y WiredTiger.