Make the MongoDB docs better! We value your opinion. Share your feedback for a chance to win $100.
Click here >
Docs Menu
Docs Home
/ /

Solución de problemas de consultas lentas en producción

Esta página cubre las causas comunes y las soluciones para consultas lentas. Si necesita ayuda adicional después de revisar las siguientes secciones, contáctenos. Apoyo técnico.

Para confirmar que su implementación está experimentando problemas con consultas lentas, verifique lo siguiente:

Para confirmar que las consultas son realmente lentas, compare la latencia actual de las consultas con los valores de referencia históricos o los objetivos de nivel de servicio. Determine si la lentitud es constante o se produce durante patrones de carga específicos, como picos de carga, trabajos por lotes o ventanas de mantenimiento.

Utilice el analizador de bases de datos y los registros de consultas lentas para identificar operaciones específicas por espacio de nombres, patrón y latencia.

Para Atlas, utilice el Utilice elAsesor de rendimiento y el Analizador de consultas para encontrar consultas con tiempos de ejecución elevados.

Confirme el estado del clúster y de los nodos. Compruebe si hay problemas con:

  • estado primario/secundario

  • atraso de la replicación

  • Elecciones frecuentes

  • Disponibilidad de nodos

  • Conmutaciones por fallo

  • Node restarts

  • Errores de almacenamiento que ocurren al mismo tiempo que períodos de consulta lentos

Inspeccione la CPU, la memoria, las operaciones de entrada/salida del disco y la utilización del disco en cada nodo, confirmando que no haya saturación sostenida. Para obtener más información, consulte la sección "Supervisión de una implementación autogestionada de MongoDB".

En Atlas, revise los paneles de métricas para detectar picos en la CPU, las IOPS, las conexiones y los fallos de página en torno al momento en que se producen consultas lentas.

Determine si se produjeron cambios recientes al mismo tiempo que las consultas lentas, tales como:

  • Publicar una solicitud

  • Cambios en el índice

  • Migraciones de esquemas

  • Redimensionamiento de la implementación

  • Cambios de parámetros

Las siguientes secciones describen las causas comunes de las consultas lentas y cómo solucionarlas.

Los siguientes problemas de indexación pueden provocar consultas lentas.

Las consultas que realizan escaneos de colecciones o utilizan índices no selectivos pueden causar una alta latencia bajo carga de producción. Identifique las consultas que no utilizan el índice esperado mediante el uso de explaincon la "executionStats" “allPlansExecution” opción o para mayor detalle. Estas opciones muestran las métricas de ejecución de todos los planes durante la fase de evaluación. Cree o refine los índices de los campos utilizados para filtrar y ordenar los resultados de la consulta.

Las consultas con que no pueden usar un índice requieren una ordenación en memoria. Esto es especialmente lento en conjuntos de resultados grandes. Puede mejorar el rendimiento sort() mediante:

  • Creación de índices compuestos que coincidan con los patrones de filtro y ordenación de la consulta.

  • Reducción del tamaño del conjunto de resultados antes de la ordenación.

Las canalizaciones de agregación deben usar $match las etapas, u otras etapas selectivas al principio, para filtrar el conjunto de datos y evitar procesar grandes volúmenes de datos en memoria. Si su canalización$sort $match tiene $sort etapas o al final, muévalas al principio siempre que sea posible.

También puede mejorar el rendimiento creando índices en los campos utilizados en las primeras etapas del proceso.

Los siguientes problemas de diseño de esquema y consulta pueden provocar consultas lentas.

Los documentos muy grandes, las matrices ilimitadas y las estructuras altamente anidadas aumentan el consumo de E/S y CPU por operación. Puede mejorar el rendimiento identificando colecciones con documentos inusualmente grandes o matrices extensas y actualizando el esquema para usar la agrupación o la referenciación cuando sea posible.

Las consultas que analizan colecciones grandes o rangos de tiempo son más lentas que aquellas que aplican filtros y límites estrictos. Puede mejorar el rendimiento de las consultas mediante:

  • Agregar filtros selectivos e indexar los campos consultados.

  • Utilizar patrones de paginación en lugar de combinaciones grandes de skip() o.limit()

  • Reducir los intervalos de tiempo para los datos de series temporales o ajustar la granularidad de la propia recopilación subyacente si es demasiado fina.

Algunos operadores y patrones de consulta impiden que MongoDB utilice los índices de forma eficiente:

  • $regex con un comodín líder

  • $nin

  • Listas $in muy grandes

  • Ramas $or excesivas

  • $ne ecuaciones de negación que impactan negativamente en el escaneo de índices

Para mejorar el rendimiento, reescribe los predicados para que sean compatibles con la indexación. Considera el uso de expresiones regulares ancladas y campos precalculados siempre que sea posible.

Las consultas lentas podrían deberse a la contención por los recursos de hardware subyacentes bajo carga de producción. Compruebe si existe una correlación entre los picos de latencia de las consultas y las métricas de CPU, IOPS y utilización de la caché. Considere el escalado vertical y/o horizontal o la redistribución de la carga de trabajo si las consultas ya están optimizadas.

Las operaciones de larga duración pueden bloquear o interferir con otras consultas. Por ejemplo:

  • Grandes compilaciones de índices

  • Escaneos de la colección

  • Heavy escribe

Utilice para identificar operaciones bloqueantes o de larga duración. Considere programar las operaciones pesadas durante las ventanas de mantenimiento. Por ejemplo, considere ejecutar la creación de índices en colecciones grandes durante las ventanas de $currentOp mantenimiento.

Las consultas dirigidas a servidores secundarios con latencia de replicación o hardware menos potente pueden provocar respuestas más lentas. Revise las preferencias de lectura y escritura del controlador. Asegúrese de que las consultas críticas en cuanto a latencia se dirijan a los nodos adecuados.

  • Vuelva a ejecutar consultas representativas y compare la latencia con los resultados anteriores y los objetivos deseados.

  • Confirme que explain("executionStats") muestra una reducción del trabajo, como un menor número de documentos examinados y un mejor uso del índice.

  • Revise los registros del generador de perfiles y de las consultas lentas para verificar lo siguiente:

    • Las consultas lentas anteriores ya no aparecen.

    • Los tiempos de consulta y el uso de recursos han disminuido.

  • Para las implementaciones de Atlas, confirme que las métricas a nivel de consulta y de clúster hayan vuelto a sus rangos normales después de los cambios.

Si necesita ayuda adicional, recopile la siguiente información:

  • Ejemplos de consultas lentas con filtro completo y cualquier proyección, ordenación y opciones aplicables, incluyendo:

    • Frecuencia aproximada

    • Latencia esperada frente a latencia observada

  • explain("executionStats") Salida para consultas lentas representativas

  • Extractos de registro relevantes y muestras del generador de perfiles que cubren el período en el que se produce la lentitud.

  • Cambios recientes en:

    • Esquema o índices

    • Tamaño, nivel o topología de la implementación

    • Patrones de lanzamiento o consulta de aplicaciones

  • Métricas del clúster o estadísticas a nivel de host que muestren el uso de CPU, memoria, E/S de disco y conexiones en torno al momento en que se producen consultas lentas.

  • Detalles sobre el entorno de implementación:

    • Atlas frente a autogestión

    • Perfil de hardware

    • Configuración de fragmentación

    • Configuración de replicación

Volver

Bloquea consultas lentas

En esta página