Supervisión del despliegue

Databases for MongoDB Las implementaciones ofrecen integración con el servicio « IBM Cloud® Monitoring » para la supervisión básica del uso de recursos, como el uso del disco y las IOPS de tu implementación. Observar las tendencias de uso puede ayudar a mitigar los problemas de rendimiento antes de que las bases de datos se vuelvan inestables debido al agotamiento de los recursos.

Uso de disco

Si te preocupa el espacio que ocupa MongoDB para almacenar tus datos, puedes ejecutar algunas consultas nativas MongoDB diagnóstico del almacenamiento de datos para averiguar el tamaño de elementos como bases de datos, colecciones e índices. Si el tamaño aproximado del conjunto de datos es conocido y fijo, puede escalar manualmente el disco para adaptarlo a los datos.

E/S de disco

El número de operaciones de entrada-salida por segundo (IOPS) en Databases for MongoDB está limitado por el tipo de volumen de almacenamiento. Los volúmenes de almacenamiento para las implementaciones de « Databases for MongoDB » son volúmenes de almacenamiento en bloque de tipo «endurance» en el nivel de 5 IOPS por GB. Si se alcanzan los límites de utilización de E/S, puede provocar que las bases de datos respondan lentamente o que no respondan. Las consultas no optimizadas, la creación de índices y la generación de nuevos índices pueden provocar picos de IOPS. Las cargas de trabajo normales de las aplicaciones también pueden superar las IOPS disponibles para tu implementación.

Puede aumentar el número de IOPS disponible en el despliegue aumentando el espacio de disco.

Para obtener más información, consulta la documentación de « MongoDB ».

Memoria caché y memoria de WiredTiger

Databases for MongoDB utiliza el motor de almacenamiento « WiredTiger », que emplea tanto la caché de memoria del sistema de archivos como una caché de memoria interna. MongoDB ofrece un mejor rendimiento cuando sirve los datos desde su memoria caché interna, un rendimiento algo menor de cuando los datos están en la memoria caché del sistema de archivos, y el menor rendimiento cuando tiene que coger los datos del disco.

El tamaño predeterminado de la caché interna es 50% of (total RAM per member - 1 GB) o 256 MB, el que sea mayor. Por ejemplo, el tamaño mínimo de memoria de una implementación de « Databases for MongoDB » es de 4096 MB por miembro de datos, por lo que la caché interna es de 1536 MB (ya que 0.5 * (4096 MB - 1024 MB) = 1536 MB.

La proporción de memoria caché interna y la del sistema de archivos no la puede configurar el usuario en el despliegue, pero se puede escalar la cantidad total de memoria para ajustar la memoria caché interna y hacer que la base de datos ofrezca un mejor rendimiento. Por ejemplo, si se amplía la memoria a 5120 MB por miembro, el tamaño de la caché interna pasa a ser de 2048 MB. 0.5 * (5120 MB - 1024 MB) = 2048 MB.

Otra forma de utilizar el escalado automático es establecer que se escale la memoria cuando la utilización de E/S de disco alcance un determinado umbral. Al aumentar la memoria disminuye la cantidad que MongoDB lee o escribe en el disco, por lo que añadir memoria puede aliviar la presión en la E/S de disco ya que se admite más almacenamiento en caché.

Encontrarás más información sobre la caché « WiredTiger » en la documentación de « MongoDB ».

Rendimiento de consultas

La documentación de MongoDB contiene diversos recursos sobre el rendimiento de las consultas, incluida una guía práctica para analizar dicho rendimiento. Una vez que tengas una idea general del rendimiento de tus consultas, también encontrarás consejos para optimizarlas.

Si quieres profundizar en el tema, puedes aprender cómo hacerlo en MongoDB gestiona los planes de consulta.

Otras herramientas de supervisión de MongoDB

También puede utilizar algunas de las funciones de supervisión nativas de MongoDB. Por ejemplo, puedes utilizar tanto mongotop y mongostat.

Ejecuta cualquiera de los informes de comandos documentados que recogen el estado de tu base de datos MongoDB.

Muchas de las utilidades y comandos de MongoDB necesitan el rol « Cluster Monitor » para ejecutarse. No forma parte del conjunto de roles predeterminado de « manager ». Otorga el rol «Cluster Monitor» al usuario « manager » en tu implementación.