Docs Menu
Docs Home
/ /

Soluciona problemas de consultas lentas en producción

Esta página cubre las causas y soluciones comunes de consultas lentas. Si necesitas soporte adicional después de revisar las siguientes secciones, ponte en contacto con Soporte técnico.

Para confirmar que tu implementación está experimentando problemas con queries lentas, verifica lo siguiente:

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

Utiliza el perfilador de base de datos y los registros de queries lentas para identificar operaciones específicas por namespace, patrón y latencia.

Para Atlas, usa el Performance Advisor y el Query Profiler para encontrar las consultas con mayor tiempo de ejecución.

Confirma la salud del clúster y del nodo. Verifica si hay problemas con:

  • Estado primario/secundario

  • atraso de la replicación

  • Elecciones frecuentes

  • Disponibilidad de nodos

  • Conmutaciones por error

  • Node restarts

  • Errores de almacenamiento que ocurren al mismo tiempo que los periodos de query lentas

Inspeccione el uso de CPU, memoria, E/S de disco y utilización de disco en cada nodo, confirmando que no haya una saturación sostenida. Para más detalles, consulta Monitorear una implementación autogestionada de MongoDB.

En Atlas, revisa las métricas de los tableros para detectar picos en la CPU, IOPS, conexiones y fallos de página alrededor del momento de las consultas lentas.

Determina si se produjeron cambios recientes al mismo tiempo que las consultas lentas, como por ejemplo:

  • Lanzar una aplicación

  • Cambios en el índice

  • Migraciones de esquemas

  • Redimensionamiento de implementación

  • Cambios de parámetros

Las siguientes secciones describen las causas más comunes de las consultas lentas y cómo resolverlas.

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

Las consultas que realizan escaneos de colección o utilizan índices no selectivos pueden causar una latencia elevada bajo carga de producción. Identifica las consultas que no utilizan el índice esperado mediante explain con la opción "executionStats" o “allPlansExecution” para alto nivel de verbosidad. Estas opciones muestran las métricas de ejecución de todos los planes durante la fase de evaluación. Crear o refinar índices para los campos utilizados para filtrar y ordenar los resultados de la query.

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

  • Creación de índices compuestos que se ajusten al filtro de query y a los patrones de ordenamiento

  • Reducir el tamaño del conjunto de resultados antes de ordenarlo

Las pipelines de agregación deben usar $match, $sort u otras etapas selectivas temprano, para filtrar el conjunto de datos y evitar procesar grandes volúmenes de datos en la memoria. Si tu pipeline tiene etapas tardías $match o $sort, muévelas antes siempre que sea posible.

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

Los siguientes problemas de diseño de esquemas y query pueden causar lentitud en las query.

Los documentos muy grandes, los arreglos sin límites y las estructuras altamente anidadas aumentan la entrada/salida y la CPU por operación. Puedes aumentar el rendimiento identificando colecciones con documentos inusualmente grandes o arreglos extensos y actualizando el esquema para usar agrupación o referencias cuando sea posible.

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

  • Agregar filtros selectivos e indexación de campos consultados

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

  • Reducir las ventanas para los datos de series de tiempo, o ajustar la granularidad de la colección subyacente si es demasiado fina.

Algunos operadores del query y patrones impiden que MongoDB use los índices de manera eficiente:

  • $regex con un comodín inicial

  • $nin

  • Listas $in muy grandes

  • Demasiadas ramas en $or

  • $ne ecuaciones de negación que afectan negativamente al escaneo de índices

Para mejorar el rendimiento, reescribe los predicados para que sean optimizados para índices. Considerar regex anclada y campos precomputados siempre que sea posible.

Las consultas lentas podrían deberse a la competencia por los recursos de hardware subyacentes bajo carga de producción. Comprueba si existe una correlación entre los picos en la latencia de query y las métricas de uso de CPU, IOPS y caché. Considere el escalado horizontal y/o vertical 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 creaciones de índices

  • escaneo de colección

  • Heavy operaciones de guardar

Use $currentOp para identificar operaciones bloqueantes o de larga duración. Considera programar operaciones pesadas durante los periodos de mantenimiento. Por ejemplo, considera ejecutar creaciones de índices en colecciones grandes durante períodos de mantenimiento.

Las queries dirigidas a secundarios con atraso de la replicación o hardware menos capaz pueden provocar respuestas más lentas. Revisa las preferencias de lectura del controlador y los niveles de confirmación de escritura (write concern). Asegúrate de que las consultas críticas de latencia se dirijan a los nodos apropiados.

  • Vuelve a ejecutar consultas representativas y compara la latencia con resultados anteriores y metas deseadas.

  • Confirme que explain("executionStats") muestra una carga de trabajo reducida, como que examina menos documentos y utiliza mejor los índices.

  • Revise los registros de perfilador y consultas lentas para verificar cualquiera de las siguientes opciones:

    • Las consultas lentas anteriores ya no aparecen.

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

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

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

  • Ejemplo de consultas lentas con filtro completo y cualquier proyección, ordenamiento y opciones aplicables, incluidos:

    • Frecuencia aproximada

    • Latencia esperada frente a latencia observada

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

  • Extractos relevantes de registros y muestras de perfilador que cubren el periodo en el que se produce lentitud

  • Cambios recientes en:

    • Esquema o índices

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

    • Patrones de liberación o query de la aplicación

  • Métricas de clúster o estadísticas a nivel de host que muestran el uso de CPU, memoria, E/S de disco y conexiones alrededor del momento en que ocurren las consultas lentas.

  • Detalles sobre el entorno de implementación:

    • Atlas versus autogestionado

    • Perfil de hardware

    • Configuración de particionado

    • Configuración de replicación

Volver

Bloquea consultas lentas

En esta página