La consulta se ejecuta lentamente

Identificación: detecte el problema

Una consulta de ejecución lenta es aquella que supera el tiempo de ejecución esperado para los requisitos empresariales. La definición de lo que constituye una consulta lenta varía según las distintas cargas de trabajo. Puede identificar las consultas lentas mediante los registros del generador de perfiles o Performance Insights.

1. Habilite el generador de perfiles si aún no lo ha hecho. Los registros de Profiler se escriben CloudWatch en Amazon en el grupo de registros:/aws/docdb/<cluster-identifier>/profiler. Utilice CloudWatch Logs Insights para consultarlos.

   Ejemplo de consulta de análisis de CloudWatch registros para obtener las 10 consultas más lentas de la colección ecommerce.products:

   
   filter ns="ecommerce.products" | sort millis desc | limit 10
               

2. Utilice Performance Insights para identificar consultas costosas prácticamente en tiempo real. Activa Performance Insights si aún no está activado.

   1. Abra la AWS consola, vaya a Amazon DocumentDB, luego a Performance Insights y seleccione la instancia de clúster.

   2. Revise el cronograma de carga de base de datos (AAS) y las consultas principales (por carga de base de datos). Amplíe el resumen de una consulta para ver las sentencias secundarias literales.

   3. Capture las consultas que requieren análisis.

   nota

   Es posible que no todas las consultas de Performance Insights sean consultas ineficientes o lentas.

Investigue: recopile información

1. El generador de perfiles proporciona el plan de ejecución de la consulta y las métricas clave asociadas a él, como millis, nreturned y planSummary (índice de uso):

   
   {
       "op": "query",
       "ts": 1721374275673,
       "ns": "test.perf",
       "command": {
           "find": "perf",
           "filter": {
               "threadRunCount": 0
           },
           "$db": "test",
           "lsid": {
               "id": {
                   "$binary": "oO2wEtpgQIK+y9KGByYnsw==",
                   "$type": "4"
               }
           },
           "$readPreference": {
               "mode": "secondaryPreferred"
           }
       },
       "cursorExhausted": true,
       "nreturned": 0,
       "responseLength": 0,
       "protocol": "op_query",
       "millis": 137,
       "planSummary": "IXSCAN",
       "execStats": {
           "stage": "FETCH",
           "nReturned": "0",
           "executionTimeMillisEstimate": "100.346",
           "inputStage": {
               "stage": "IXSCAN",
               "nReturned": "0",
               "executionTimeMillisEstimate": "100.342",
               "indexName": "threadRunCount_1"
           }
       },
       "client": "172.31.6.165:43154",
       "appName": "ProdAppTester14",
       "user": "adminuser"
   }
               

   Para buscar las consultas de COLLSCAN:

   
   filter planSummary="COLLSCAN" | sort millis desc | limit 20
               

2. Utilice Performance Insights para analizar las tendencias de ejecución de consultas, como las esperas, la carga y el impacto en los recursos (p. ej., IOPS o CPU por consulta) en tiempo real.

   Como Performance Insights no proporciona el plan de ejecución de la consulta, capture la consulta y ejecute explain («ExecutionStats») en la consulta en su clúster de Amazon DocumentDB:

   
   db.ecommerce.products.find().explain("executionStats")
               

3. Si lo desea, correlacione las métricas del generador de perfiles con los datos de Performance Insights (por ejemplo, compare las consultas de alto número de milisegundos del generador de perfiles con las consultas principales de Performance Insights).

Diagnostique: encuentre la causa raíz

En este paso, diagnostique el plan de consulta para identificar posibles optimizaciones. Utilice el siguiente flujo: síntoma → causa probable:

• Síntoma: Resumen del plan: «COLLSCAN»

  Causa: falta el índice o es incorrecto.

• Síntoma: la agregación es lenta con $group/$sort

  Causa: es posible que la canalización de agregación esté procesando demasiados datos en la memoria.

• Síntoma: latencias altas, mientras que Performance Insights muestra la carga de base de datos agrupada por esperas de E/S, aunque se utilizan índices (PlanSummary: «IXSCAN»).

  Causa: consultas I/O enlazadas; los índices o el conjunto de trabajo superan la caché de búfer disponible en la instancia.

• Síntoma: el PI muestra los estados de espera de la CPU, mientras que el AAS es alto debido a las pocas consultas

  Causa: consultas vinculadas a la CPU (agregaciones complejas, $regex).

• Síntoma: muchas consultas lentas, pero ninguna muestra un planSummary caro

  Causa: cuello de botella externo (red, limitaciones, tareas de mantenimiento, volumen de consultas).

Resolver: solucione el problema

Cuando implemente correcciones, valide siempre con explain («ExecutionStats») y supervise la carga de la base de datos Performance Insights.

1. Resumen del plan: «COLLSCAN»

   • Cree un índice específico.

     Ejemplo: para consultas frecuentes que filtran por {categoría, precio} y ordenan por precio descendente:

     
     db.products.createIndex({ category: 1, price: -1 })
                       

2. la agregación es lenta con $group/$sort

   • Empuje $match y $project con antelación para reducir el flujo de documentos hacia $group/$sort.

   • Limite el número de campos al principio del proceso:

     
     db.products.explain("executionStats").aggregate([
       { $match: { category: "Electronics", price: { $gt: 0 } } },   // early filter
       { $project: { price: 1, category: 1 } },                     // reduce document size
       { $group: { _id: "$category", avgPrice: { $avg: "$price" } } }
     ])
                       

3. latencias altas, mientras que Performance Insights muestra la carga de base de datos agrupada por esperas de E/S

   • Valide si BufferCacheHitRatio el nivel de ReadiOps de la instancia es bajo o alto. Aumente la memoria de la instancia (actualice la clase de instancia, por ejemplo, r6g.large → r6g.xlarge) o utilice la clase de instancia. NVMe

   • Reduzca la huella indexada.

   • Agregue réplicas de lectura para reducir el tráfico de lectura (utilice la configuración ReadPreference para redirigir el tráfico de las réplicas si la consulta tolera la coherencia final).

4. El PI muestra los estados de espera de la CPU, mientras que el AAS es alto debido a las pocas consultas

   • Sustituya la costosa opción $regex por búsquedas de prefijos indexados o por el índice $text.

   • Escritura por lotes (inserción) para reducir la amplificación de la escritura.

nota

Pruebe siempre los cambios en un entorno inferior (no de producción) antes de promocionar esos cambios a producción.