Localización de solicitud lenta

Localización de fallas

DDS le permite ver registros de consultas lentos en la consola. Puede comenzar desde la operación más lenta registrada en el registro y optimizar las operaciones una por una.

• Si una consulta tarda más de 1s, la operación correspondiente puede ser anormal. Es necesario analizar el problema basado en la situación real.
• Si una consulta tarda más de 10 segundos, la operación necesita ser optimizada.
  

  Si una operación agregada toma más de 10 segundos, es normal.

Método de análisis

1. Conéctese a la base de datos.
   • Para conectarse a una instancia de clúster, consulte Conexión a una instancia de clúster.
   • Para conectarse a una instancia de conjunto de réplicas, consulte Conexión a una instancia de conjunto de réplicas.
   • Para conectarse a una instancia de nodo único, consulte Conexión a una instancia de nodo único.

2. Ejecute el siguiente comando para comprobar el plan de ejecución de una consulta lenta:

   explain()

   Ejemplo:

   db.test.find({"data_id" : "ae4b5769-896f-465c-9fbd-3fd2f3357637"}).explain();
   db.test.find({"data_id" : "775f57c2-b63e-45d7-b581-3822dba231b4"}).explain("executionStats");

   Una consulta cubierta no necesita leer un documento, pero devuelve directamente un resultado de un índice, que es muy eficiente. Puede utilizar índices de cobertura tanto como sea posible. Si el resultado de explica (explica) muestra que indexOnly es verdadero, la consulta está cubierta por un índice.

3. Analizar el plan de ejecución.
   1. Compruebe el tiempo de ejecución.

      Cuanto más pequeños sean los valores de los siguientes parámetros, mejor será el rendimiento: executionStats.executionStages.executionTimeMillisEstimate y executionStats.executionStages.inputStage. executionTimeMillisEstimate

      Tabla 1 Descripción del parámetro

      Parámetro	Descripción
      executionStats.executionTimeMillis	Selección del plan de ejecución y tiempo de ejecución
      executionStats.executionStages.executionTimeMillisEstimate	Tiempo de finalización del plan de ejecución óptimo
      executionStats.executionStages.inputStage. executionTimeMillisEstimate	Tiempo de finalización de la ejecución de la subfase del plan de ejecución óptimo

   2. Compruebe el número de registros escaneados.

      Si los tres elementos en Tabla 2 tienen el mismo valor, el rendimiento de la consulta es el mejor.

      Tabla 2 Descripción del parámetro

      Parámetro	Descripción
      executionStats. nReturned	Número de documentos que coinciden con los criterios de búsqueda
      executionStats .totalKeysExamined	Número de filas analizadas a través de índices
      executionStats .totalDocsExamined	Número de documentos escaneados

   3. Compruebe el estado de la etapa.
      Las combinaciones de estados de escenario con mejor rendimiento son las siguientes:

      • Fetch+IDHACK
      • Fetch+ixscan,
      • Limit+ (Fetch+ixscan)
      • PROJECTION+ixscan

      Tabla 3 Descripción de estado

      Nombre de estado	Descripción
      COLLSCAN	Escaneo completo de la tabla
      SORT	Clasificación en memoria
      IDHACK	consulta basada en _id
      TEXT	Índice de Full-text
      COUNTSCAN	Número de índices no utilizados
      FETCH	Búsqueda de índices
      LIMIT	Uso de Límite para limitar el número de registros devueltos
      SUBPLA	$or etapa de consulta sin usar un índice
      PROJECTION	Número de índices utilizados
      COUNT_SCAN	Número de índices utilizados

Plan de optimización

• Para consultas sin índices, cree índices basados en los criterios de búsqueda.
• Se pueden crear índices hash para consultas de puntos.
• Cree índices compuestos para consultas de varios campos donde un solo campo es altamente repetido.
• Cree un índice ascendente o descendente para las búsquedas de rangos con conjuntos de resultados ordenados.
• Los índices compuestos son aquellos índices que ordenan los resultados de la consulta por prefijo, por lo que la secuencia de las condiciones de la consulta debe ser la misma que la de los campos de índice.
• Para colecciones particionadas (tablas) y colecciones grandes (con más de 100,000 de registros), no utilice consulta difusa (o no utilice LIKE) para tablas con una gran cantidad de datos. Como resultado, se escanea un gran número de registros. Puede consultar datos basados en el campo de índice, filtrar colecciones pequeñas y, a continuación, realizar consultas difusas.
• No use $not. MongoDB no indexa los datos que faltan. La consulta $not requiere que todos los registros se analicen en una única colección de resultados. Si $not es la única condición de consulta, se realizará un análisis de tabla completa en la colección.
• Si usa $and, pon las condiciones con menos coincidencias antes que otras condiciones. Si usa $or, pon primero las condiciones con más coincidencias.
• Compruebe la línea de base de rendimiento de las especificaciones de instancia y analice si se pueden cumplir los requisitos de servicio actuales. Si se alcanza el cuello de botella de rendimiento de la instancia actual, actualice las especificaciones de la instancia de manera oportuna.