Troubleshoot high CPU utilization on an ApsaraDB for MongoDB instance - ApsaraDB for MongoDB

El alto uso de CPU en una instancia de ApsaraDB for MongoDB, que en ocasiones se acerca al 100%, ralentiza las operaciones de lectura y escritura e interrumpe las operaciones del negocio. Siga los pasos de diagnóstico a continuación para identificar y resolver la causa raíz.

Compruebe las operaciones en ejecución

Conéctese a la instancia mediante el mongo shell. Los procedimientos de conexión varían según la arquitectura de la instancia:

Connect to a standalone instance by using the mongo shell

Ejecute db.currentOp() para listar todas las operaciones que se ejecutan actualmente en la instancia:

db.currentOp()

Salida de ejemplo:

{
    "desc" : "conn632530",
    "threadId" : "140298196924160",
    "connectionId" : 632530,
    "client" : "11.xxx.xxx.236:57052",
    "active" : true,
    "opid" : 1008837885,
    "secs_running" : 0,
    "microsecs_running" : NumberLong(70),
    "op" : "update",
    "ns" : "mygame.players",
    "query" : {
        "uid" : NumberLong(31577677)
    },
    "numYields" : 0,
    "locks" : {
        "Global" : "w",
        "Database" : "w",
        "Collection" : "w"
    },
    ....
}

Preste atención a los siguientes campos para identificar operaciones problemáticas:

Field	Description	When to act
`client`	El cliente que envió la solicitud	Utilice este valor para rastrear la solicitud hasta su origen
`opid`	ID único de la operación	Ejecute `db.killOp(opid)` para detener la operación si es necesario
`secs_running`	Tiempo de ejecución de la operación, en segundos	Investigue las operaciones con valores inesperadamente altos
`microsecs_running`	Tiempo de ejecución de la operación, en microsegundos	Investigue las operaciones con valores inesperadamente altos
`ns`	El namespace (colección) que se está escaneando	Compare con los registros de consultas lentas para encontrar colecciones con alta actividad
`op`	Tipo de operación: `query`, `insert`, `update` o `delete`	—
`locks`	Información de bloqueos de la operación	Consulte FAQ: Concurrency

Para obtener más información sobre db.currentOp(), consulte db.currentOp().

Una causa común de los picos de CPU es una operación de O&M, como un escaneo completo de colección, que se ejecuta junto con su carga de trabajo habitual. Si db.currentOp() muestra una operación con un valor alto en secs_running que no esperaba, deténgala:

db.killOp(<opid>)

Reemplace <opid> con el valor del campo opid obtenido en la salida de db.currentOp(). Para obtener más información, consulte db.killOp().

Analice los registros de consultas lentas

Si el uso de CPU aumenta inmediatamente después de iniciar la aplicación y se mantiene alto, pero db.currentOp() no muestra operaciones claramente problemáticas, es probable que la causa sea un patrón de consultas lentas que se acumulan con el tiempo.

Consulte los registros de consultas lentas en la consola de ApsaraDB for MongoDB. Para obtener más información, consulte View slow query logs.

Una entrada de registro de consulta lenta de ejemplo tiene el siguiente aspecto:

{
  "atype": "slowOp",
  "param": {
    "op": "query",
    "ns": "abbott_analysis.uaidScanInfo",
    "query": {
      "find": "uaidScanInfo",
      "filter": {
        "dateType": 2,
        "companyCode": "GMP"
      },
      "ntoreturn": -1,
      "sort": {
        "scanDateTime": -1
      }
    },
    "keysExamined": 0,
    "docsExamined": 2181021,
    "hasSortStage": true,
    "cursorExhausted": true,
    "numYield": 17059,
    "locks": { ... },
    "nreturned": 0,
    "responseLength": 20,
    "millis": 4878,
    "planSummary": "COLLSCAN"
  },
  "result": "OK"
}

Busque los siguientes patrones en los registros de consultas lentas:

Escaneos completos de colección (`COLLSCAN`, `docsExamined`)

planSummary: COLLSCAN indica que la consulta escaneó toda la colección sin usar un índice. El campo docsExamined muestra cuántos documentos se examinaron; cuanto mayor sea este número, más CPU consumirá la consulta.

Cree un índice en los campos consultados para solucionar esto:

db.<collection>.createIndex({ <field>: 1 })

Índices ineficientes (`IXSCAN`, `keysExamined`)

Cuando una consulta utiliza un índice, planSummary muestra IXSCAN. El campo keysExamined indica cuántas claves de índice se escanearon. Cuanto mayor sea el valor, más recursos de CPU ocupará la solicitud.

Ejemplo de selectividad de índice

Considere una colección donde el campo x solo tiene dos valores posibles (1 o 2), mientras que y abarca un rango mucho más amplio (de 1 a 100000). Para la consulta { x: 1, y: 2 }:

{ x: 1, y: 1 }
{ x: 1, y: 2 }
...
{ x: 1, y: 100000 }
{ x: 2, y: 1 }
...

Index	Selectivity	Reason
`db.createIndex({ x: 1 })`	Deficiente	La mitad de la colección comparte el mismo valor de `x`
`db.createIndex({ x: 1, y: 1 })`	Deficiente	El campo principal `x` sigue teniendo baja selectividad
`db.createIndex({ y: 1 })`	Adecuado	`y` tiene un rango amplio: pocos documentos comparten el mismo valor
`db.createIndex({ y: 1, x: 1 })`	Adecuado	El campo principal `y` elimina la mayoría de los documentos de inmediato

Indexe primero el campo de alta selectividad. Para obtener más información, consulte Compound indexes.

El exceso de índices afecta el rendimiento de escritura y actualización. Si su aplicación implica un gran número de operaciones de escritura y utiliza índices, el rendimiento de la aplicación puede verse afectado. Revise y elimine los índices no utilizados si el rendimiento de escritura también se ha degradado.

Ordenamiento en memoria (`SORT`, `hasSortStage`)

hasSortStage: true significa que la instancia ordenó los resultados de la consulta en memoria porque ningún índice pudo satisfacer el criterio de ordenamiento. Los ordenamientos en memoria sobre conjuntos de resultados grandes consumen una cantidad significativa de CPU.

Si los registros de consultas lentas contienen la palabra clave SORT, cree un índice en los campos utilizados en la cláusula de ordenamiento:

db.<collection>.createIndex({ <sort-field>: 1 })

Otras operaciones con alto consumo de CPU

La creación de índices y los pipelines de aggregation (que combinan recorrido, filtrado, actualizaciones y ordenamiento) también pueden provocar un alto uso de CPU. Aplique el mismo enfoque de diagnóstico: revise docsExamined, keysExamined, hasSortStage y planSummary en los registros de consultas lentas.

Evalúe la capacidad del servicio

Si todas las consultas utilizan índices adecuados y el uso de CPU permanece alto, es posible que la instancia haya alcanzado su límite de capacidad.

Revise los datos de monitoreo para comprender su patrón de uso de recursos. Para obtener más información, consulte View monitoring data y Node monitoring (previously basic monitoring).
Pruebe su base de datos MongoDB para determinar si la instancia actual ofrece el rendimiento y la capacidad de servicio necesarios para su carga de trabajo.

Si necesita actualizar la instancia, consulte Change the configurations of an instance o Change the number of nodes in a replica set instance.

Referencia rápida

Command	Purpose
`db.currentOp()`	Lista todas las operaciones que se ejecutan actualmente en la instancia
`db.killOp(<opid>)`	Detiene una operación específica mediante su ID de operación
Consulte los registros de consultas lentas en la consola	Identifique consultas lentas sin conectarse a la instancia