Las implementaciones de MongoDB admiten bases de datos a gran escala con un alto volumen de transacciones, lo que hace que el ajuste del rendimiento sea esencial. El ajuste regular ayuda a identificar problemas en el clúster de forma temprana, lo que permite abordarlos antes de que afecten la capacidad de respuesta o la estabilidad del sistema.
Este documento aborda algunos métodos comunes para optimizar el rendimiento de su implementación mediante el ajuste del rendimiento y métricas útiles. Estos métodos se aplican tanto a clústeres de MongoDB Atlas como a implementaciones autogestionadas. Sin embargo, el proceso de ajuste es mucho más sencillo con MongoDB Atlas, que automatiza numerosas tareas y optimiza la eficiencia. Para más información sobre el rendimiento, consulte Rendimiento de MongoDB.
Ejecute sus consultas a máxima velocidad
Para garantizar un rendimiento óptimo de las consultas, puede utilizar métricas que revelen problemas de rendimiento de las consultas y le indiquen qué hacer si encuentra consultas lentas.
Los archivos de registro de MongoDB registran el tiempo y el método de ejecución de cada consulta, lo que permite detectar consultas lentas. El generador de perfiles de base de datos registra las consultas que superan un umbral especificado.
Si una consulta es lenta, primero acceda a sus planes de consulta. Para obtener más información sobre cómo encontrar datos de planes de consulta, consulte "Explicar resultados".
Asegúrate de que la query haya realizado un escaneo de índice en lugar de un escaneo de colección.
Un escaneo de índice limita la cantidad de documentos que MongoDB inspecciona, mientras que un escaneo de colección requiere que MongoDB lea todos los documentos de una colección. Para obtener más información sobre cómo interpretar los resultados del plan, consulte Interpretar y explicar los resultados del plan.
Si ve muchos escaneos de colecciones en los resultados de su plan de explicación, considere agregar un índice.
Nota
Los índices pueden ralentizar las escrituras y actualizaciones, por lo que tener demasiados índices subutilizados puede dificultar las modificaciones o inserciones de documentos, dependiendo de su carga de trabajo.
Métricas de consulta
También puede utilizar las siguientes métricas de consulta para garantizar que su consulta se ejecute a la máxima velocidad:
metrics.queryExecutor.scannedLe indica cuántos documentos se escanearon para devolver los resultados de su consulta.Idealmente, la proporción de documentos escaneados con respecto a los documentos devueltos es 1:1, lo que significa que MongoDB devuelve todos los documentos. Normalmente, la proporción es mayor que 1, lo que indica que MongoDB no devuelve algunos documentos escaneados.
La relación puede ser menor que 1 o incluso 0, lo que indica una consulta cubierta donde el índice contiene todos los datos necesarios.
Si MongoDB está escaneando una gran cantidad de documentos para responder a su consulta, es posible que falten índices o que necesite optimizar su consulta.
metrics.operation.scanAndOrderIndica el esfuerzo del servidor para ordenar los resultados de la consulta.Un número alto de escaneo y orden, como 20 o más, indica que el servidor tiene que ordenar los resultados, lo que aumenta el tiempo de los resultados de la consulta y la carga de memoria del servidor.
Para corregir un número alto de escaneo y orden, ordene los índices según los requisitos de la consulta o agregue los índices faltantes. Generalmente, ordene los índices de árbol b en orden ascendente desde el campo principal del índice, si se trata de un índice compuesto.
La métrica Número de ticket de WiredTiger refleja el rendimiento del motor de almacenamiento de WiredTiger.
Los tickets de lectura y escritura de WiredTiger son el mecanismo de control de concurrencia del motor de almacenamiento WiredTiger para gestionar el número de transacciones concurrentes. A partir de la versión 7.0, MongoDB utiliza un algoritmo dinámico para ajustar el número máximo de transacciones concurrentes del motor de almacenamiento, optimizando el rendimiento de la base de datos durante la sobrecarga del clúster.
Los tickets de lectura y escritura controlan el número máximo de transacciones simultáneas. El número de ticket de WiredTiger siempre debe ser 128. Valores persistentes inferiores a 128 indican un retraso en el servidor y posibles problemas.
Puede usar el comando para comprobar la cantidad actual de tickets de
serverStatusqueues.executionlectura y escritura, así como su uso. Consulte la sección para comprender la carga actual y la disponibilidad de tickets.Para solucionar un número de ticket bajo de WiredTiger:
Asegúrese de que la función Ajuste dinámico esté habilitada para administrar la asignación de tickets automáticamente.
Asegúrese de que su clúster tenga recursos suficientes, como CPU y memoria, para manejar la carga de trabajo.
Si está utilizando MongoDB 3.2 o una versión anterior, actualice a una versión posterior que utilice WiredTiger.
Si necesita ajustar manualmente el número máximo de transacciones simultáneas, puede modificar los parámetros
storageEngineConcurrentReadTransactionsstorageEngineConcurrentWriteTransactionsy.
Nota
Tenga cuidado al modificar y, ya que cambiar estas configuraciones puede causar problemas de rendimiento o errores. Le recomendamos consultar con el soporte de MongoDB antes de cambiar estos storageEngineConcurrentReadTransactions storageEngineConcurrentWriteTransactionsparámetros.
Antipatrones de la estructura del documento
El plan de consulta no contiene métricas que revelen antipatrones en la estructura del documento, pero puede buscarlos al depurar consultas lentas. Tenga cuidado con las siguientes prácticas de consulta incorrectas más comunes que afectan el rendimiento:
Matrices no enlazadas: Las matrices de un documento que pueden crecer sin límite de tamaño causan problemas de rendimiento, ya que cada vez que se actualizan, MongoDB debe reescribirlas en el documento. Para más información, consulte Evitar matrices no enlazadas.
Documentos incrustados sin límites: MongoDB permite insertar documentos dentro de otros documentos, con hasta 128 niveles de anidación. Cada documento de MongoDB, incluidos los incrustados, tiene un límite de tamaño de 16MB. Un número excesivo de documentos incrustados puede causar problemas de rendimiento.
Para mitigar el exceso de documentos incrustados, traslade los documentos incrustados a colecciones separadas y haga referencia a ellos desde el documento original. Para más información consulta Documentos hinchados.
Asegúrese de tener una base de datos de máxima velocidad
MongoDB cuenta con miles de métricas que monitorizan todos los aspectos del rendimiento de la base de datos, incluyendo la lectura, escritura y consultas, además de garantizar que las tareas de mantenimiento en segundo plano, como las copias de seguridad, no afecten negativamente al rendimiento. Las siguientes métricas ayudan a detectar problemas con la base de datos para garantizar su rendimiento óptimo.
Retraso de replicación
El retraso en la replicación se produce cuando un miembro secundario de un conjunto de réplicas se queda atrás del principal. Para comprender la causa del retraso, puede examinar las métricas relacionadas con el registro de operaciones. Sin embargo, los siguientes problemas son las causas más comunes del retraso en la replicación:
Un problema de red entre el primario y el secundario, que hace que los nodos sean inaccesibles
Un nodo secundario que aplica datos más lentamente que el nodo principal
Capacidad de escritura insuficiente, en cuyo caso debe agregar más fragmentos
Operaciones lentas en el nodo principal, lo que bloquea la replicación
Problemas de rendimiento del bloqueo
El sistema de bloqueo interno de MongoDB permite realizar consultas simultáneas, evitando conflictos de escritura y lecturas inconsistentes. Los problemas de rendimiento derivados del bloqueo ocurren cuando el número restante de tickets de lectura o escritura disponibles llega a cero, lo que significa que cualquier nueva solicitud de lectura o escritura se pondrá en cola hasta que haya un nuevo ticket disponible.
Los problemas de rendimiento de bloqueo pueden indicar índices subóptimos y patrones de diseño de esquema deficientes, lo que puede provocar que los bloqueos se mantengan durante más tiempo del necesario.
Cursores abiertos
Si el número de cursores abiertos aumenta sin un crecimiento correspondiente del tráfico, esto podría ser el resultado de consultas mal indexadas o consultas de larga duración debido a grandes conjuntos de resultados.
Clústeres sobrecargados
Al optimizar el rendimiento, es importante reconocer cuándo el tráfico total, o el rendimiento de las transacciones en el sistema, supera la capacidad planificada del clúster. Al monitorear el crecimiento del rendimiento, puede ampliar la capacidad del clúster de forma eficiente.
Las siguientes métricas pueden ayudarle a monitorizar el rendimiento de su clúster. Para encontrarlas, ejecute el comando y examine los campos especificados a serverStatus continuación.
Operaciones de lectura y escritura
Las métricas de operaciones de lectura y escritura indican la cantidad de trabajo que realiza el clúster. Puede encontrar las operaciones de lectura mediante el campoopcounters.queryy las de escritura medianteopcounters.insert, opcounters.updateyopcounters.delete, que cuentan el número total de operaciones de inserción, actualización y eliminación, respectivamente.
La relación entre lecturas y escrituras depende de la naturaleza de las cargas de trabajo que se ejecutan en el clúster.
La monitorización de las operaciones de lectura y escritura a lo largo del tiempo permite establecer rangos y umbrales normales.
A medida que las tendencias en las operaciones de lectura y escritura muestran un crecimiento en el rendimiento, puede aumentar gradualmente la capacidad.
Métricas de documentos y ejecutor de consultas
Las métricas de documentos y el ejecutor de consultas indican si el clúster está demasiado ocupado. Al igual que con las métricas de operaciones de lectura y escritura, no existe un valor correcto o incorrecto para estas métricas, pero tener una idea clara de lo que es normal ayuda a discernir si el bajo rendimiento se debe a un gran tamaño de la carga de trabajo o a otras razones.
Para recuperar las métricas del documento, acceda a metrics.keysExamined los metrics.totalExecMicros campos y. Para recuperar las métricas del ejecutor de consultas, examine el metrics.fromPlanCache campo. Puede encontrar todos estos campos mediante la $queryStats etapa de agregación.
MongoDB actualiza las métricas de los documentos cada vez que encuentras o insertas un documento. Cuantos más documentos encuentres, insertes, actualices o elimines, mayor será la actividad de tu clúster.
Un rendimiento bajo en un clúster que tiene mucha capacidad generalmente indica problemas de consulta.
El ejecutor de consultas le indica cuántas consultas se están procesando utilizando dos puntos de datos:
Escaneado: la tasa promedio por segundo durante el período de muestra seleccionado de elementos de índice escaneados durante las consultas y la evaluación del plan de consulta.
Objetos escaneados: la velocidad promedio por segundo durante el período de muestra seleccionado de documentos escaneados durante las consultas y la evaluación del plan de consulta.
Métricas de hardware y red
Las métricas de hardware y red pueden indicar que el rendimiento está aumentando y superará la capacidad de la infraestructura informática. Estas métricas se recopilan del sistema operativo y la infraestructura de red. Para que estas métricas sean útiles para el diagnóstico, es necesario tener una idea de lo que es normal.
Si ejecuta MongoDB en sus instalaciones, es posible que pueda ver las métricas de hardware y red mediante Ops Manager, según su sistema operativo.
Si bien hay muchas métricas para realizar un seguimiento, algunas métricas importantes para las que se debe tener un rango de referencia son:
Latencia del disco
IOPS de disco
Número de conexiones
Clúster y recursos clave
Un clúster MongoDB utiliza una variedad de recursos que proporciona la infraestructura de red y computación subyacente.
Número de conexiones de clientes
La métrica "Número actual de conexiones de cliente", ubicada en el connections.current campo del serverStatus documento, puede indicar la carga total de un sistema. Monitorear los rangos normales en diferentes momentos del día o la semana puede ayudarle a identificar rápidamente picos de tráfico.
Una métrica relacionada, el porcentaje de conexiones utilizadas, puede indicar cuándo MongoDB está cerca de quedarse sin conexiones disponibles.
Métricas de almacenamiento
Las métricas de almacenamiento rastrean cómo MongoDB utiliza el almacenamiento persistente. En el motor de almacenamiento de WiredTiger, cada colección y cada índice son archivos individuales. Al actualizar un documento en una colección, MongoDB reescribe el documento completo.
Si las métricas de espacio de memoria
dbStats.dataSizecomo,,dbStats.indexSizedbStats.storageSizeo la cantidad de documentos en la base de datos muestran un cambio inesperado significativo mientras el tráfico de la base de datos permanece dentro de rangos normales, puede indicar problemas como eliminación o corrupción de datos, crecimiento inesperado de datos o cambios de índice.Una caída repentina en puede indicar una gran cantidad de datos eliminados. Si esta caída es inesperada, debería investigar
dbStats.dataSizerápidamente.
Métricas de memoria
Las métricas de memoria muestran cómo MongoDB utiliza la memoria virtual de la infraestructura informática que aloja el clúster. Puede encontrar las métricas de memoria en el documento, en los mem resultados serverStatus de.
Un número creciente de fallas de página o una cantidad creciente de datos modificados pero aún no escritos en el disco pueden indicar problemas relacionados con la cantidad de memoria disponible para el clúster.
Las métricas de caché pueden ayudar a determinar si el conjunto de trabajo está superando el caché disponible.
Errores críticos
MongoDB crea afirmaciones principalmente a través de errores que MongoDB captura como parte de su proceso de registro.
Monitorear el número de aserciones creadas con distintos niveles de gravedad puede proporcionar una primera indicación de problemas inesperados. Las aserciones pueden ser aserciones de mensaje (el tipo más grave), aserciones de advertencia, aserciones regulares y aserciones de usuario.