El uso de CPU es una métrica de monitoreo crítica para una instancia de ApsaraDB for MongoDB. Un consumo excesivo de CPU ralentiza las respuestas de MongoDB e incluso puede dejar sus servicios no disponibles. Este tema describe cómo consultar el uso de CPU de una instancia, las causas comunes de este problema y las estrategias de optimización.
Cómo consultar el uso de CPU
Consultar los gráficos de monitoreo: En la página Monitoring Information de la consola de ApsaraDB for MongoDB, puede consultar el uso de CPU de su instancia de ApsaraDB for MongoDB. Para obtener más información sobre la granularidad de recopilación y el procedimiento, consulte basic monitoring.
ApsaraDB for MongoDB ofrece diversas combinaciones de nodos para las arquitecturas de las instancias. Seleccione un nodo para consultar su uso de CPU.
Instancias de conjunto de réplicas: una instancia de conjunto de réplicas consta de un nodo primario, uno o más nodos secundarios, un nodo oculto y uno o más nodos de solo lectura opcionales.
En la arquitectura de clúster fragmentado (sharded cluster), el uso de CPU de cada fragmento es igual al de un conjunto de réplicas. Configserver solo almacena metadatos de configuración y rara vez provoca un cuello de botella de CPU, por lo que generalmente se puede ignorar. El uso de CPU de los nodos de enrutamiento Mongos suele depender de los conjuntos de resultados de agregación y del número de solicitudes concurrentes.
El uso de CPU también depende de las especificaciones de la instancia. Por ejemplo, si una instancia cuenta con 8 núcleos de CPU y 16 GB de memoria, y presenta un uso de CPU del 100%, significa que los 8 núcleos están agotados. En este caso, el uso de CPU se muestra como 100% y no como 800%.
Causas comunes
Escaneo excesivo de documentos
ApsaraDB for MongoDB es compatible con el procesamiento multihilo. Si una sola consulta necesita escanear grandes cantidades de documentos, el hilo que ejecuta la consulta ocupa recursos de CPU durante más tiempo. Cuando las solicitudes pendientes o las consultas que requieren escanear muchos documentos presentan una alta concurrencia, la instancia donde se ejecutan dichas consultas registra un uso elevado de CPU. El uso de CPU de una instancia tiene una relación directa con el número total de documentos escaneados. Las consultas que suelen requerir el escaneo de grandes volúmenes de documentos son frecuentes en los siguientes escenarios:
-
Escaneo completo de colección
Si encuentra la palabra clave
COLLSCANen el registro de consultas lentas o en la colección system.profile, significa que una consulta realizó un escaneo completo de la colección. Debe habilitar el generador de perfiles de la base de datos para usar la colección system.profile. Para obtener más información sobre cómo consultar los registros de consultas lentas y utilizar el generador de perfiles, consulte Slow query logs.Para obtener más información sobre cómo interpretar los planes de ejecución de consultas, consulte Explain Results y Cursor Methods.
-
Diseño y uso inadecuado de índices
Preste especial atención a cualquier consulta frecuente cuyo valor
docsExamined(número de documentos escaneados) supere los 1,000. Además del escaneo completo de colección, las siguientes situaciones pueden generar un valor alto dedocsExamined:Cuando se usan varias condiciones de filtro, pero no se utiliza un índice compuesto o no se cumple el principio de coincidencia de prefijos.
La consulta es compleja o involucra muchas operaciones de agregación, lo cual puede derivar en políticas de análisis sintáctico ineficientes o en índices imposibles de optimizar.
Se evalúa incorrectamente la selectividad de un campo de datos frente a su frecuencia de ejecución, por lo que no se alcanza el equilibrio óptimo.
Concurrencia excesiva
Si se envían grandes cantidades de solicitudes de servicio y la concurrencia es demasiado alta, el uso de CPU aumenta. Para resolver este problema, puede agregar núcleos de CPU tras confirmar que no existen problemas en las consultas.
Aunque una instancia admite un número máximo total de conexiones muy alto, su capacidad para procesar conexiones activas está limitada por sus núcleos de CPU. Cuando el número de conexiones activas supera la cantidad de núcleos, la contención de recursos de CPU puede provocar colas de hilos y acumulación de tareas. Esto genera respuestas lentas incluso cuando el monitoreo reporta un uso general de CPU bajo.
Otras causas
Se establecen muchas conexiones de corta duración. En versiones posteriores a MongoDB 3.X, el mecanismo de autenticación predeterminado es SCRAM-SHA1, el cual requiere operaciones intensivas de CPU, como el cálculo de hash. Si las conexiones de corta duración presentan una alta concurrencia, el cálculo de hash consume múltiples veces más recursos de CPU e incluso los agota. En este caso, los registros operativos contienen numerosos mensajes de error saslStart. Para optimizar las conexiones de corta duración de PHP en escenarios de alta concurrencia, ApsaraDB for MongoDB mejora el método de reescritura de funciones aleatorias integradas en la capa del kernel. Esto ayuda a reducir el uso de CPU en la instancia.
-
Los índices de tiempo de vida (TTL) provocan que un nodo secundario consuma más CPU que el nodo primario. En este caso, puede ignorar el uso elevado de CPU de dicho nodo.
MongoDB 3.2 y versiones posteriores admiten replicación multihilo. La concurrencia de reproducción de oplogs la determina el parámetro replWriterThreadCount, cuyo valor predeterminado es 16. Los nodos secundarios no gestionan escrituras de servicio. Sin embargo, en algunos escenarios el uso de CPU de un nodo secundario puede superar al del nodo primario. Por ejemplo, si configura la eliminación automática basada en TTL para una colección en el nodo primario, el sistema elimina datos en lotes según el índice de la columna de tiempo, lo cual resulta eficiente. El sistema convierte esa operación en muchas eliminaciones individuales y las envía al nodo secundario. En el nodo secundario, la reproducción de oplogs es menos eficiente, por lo que la reproducción multihilo eleva fácilmente el uso de CPU de ese nodo.
Las eliminaciones por TTL pueden quitar miles de documentos caducados por segundo. El aumento resultante en el uso de CPU y en la E/S de disco representa una carga esperada. Escale verticalmente la instancia cuando la carga de trabajo requiera más capacidad, o espere a que finalice la limpieza de datos fragmentados y luego habilite el balanceador para redistribuir los datos.
En un clúster fragmentado, investigue más a fondo si el uso de CPU no disminuye y el rendimiento de inserción no mejora después de limpiar los documentos huérfanos. En CloudDBA o en las métricas de monitoreo, compare la caché sucia y la tasa de eliminación por TTL de cada fragmento. Una caché sucia elevada puede hacer que los hilos de la aplicación participen en el vaciado de páginas sucias, mientras que una tasa de eliminación por TTL inusualmente alta en un fragmento indica una carga de eliminación desequilibrada.
Métodos de solución de problemas
Consultar y finalizar sesiones activas
Si las sesiones de una instancia en funcionamiento normal aumentan repentinamente al 100%, la causa suele ser un cambio en la aplicación. Entre las causas comunes se encuentran el escaneo de demasiados documentos, la ordenación y agregación de datos, y un pico en el tráfico del servicio. Puede solucionar el problema de la siguiente manera:
En la consola de ApsaraDB for MongoDB, vaya a la página para consultar las sesiones activas. Analice las consultas que tarden más de lo esperado y finalice la sesión activa o aplique otras medidas correctivas.
Para consultar y analizar los detalles de las sesiones activas, ejecute el comando db.currentOp() proporcionado por MongoDB. Si es necesario, ejecute el comando db.killOp() para finalizar de forma activa las consultas lentas que no terminen dentro del periodo de ejecución esperado. Para obtener más información, consulte db.currentOp() y db.killOp().
Registrar y consultar registros
Cuando el uso de CPU aumenta de forma anómala, analice el registro de consultas lentas o el registro de auditoría para identificar las solicitudes problemáticas. Busque palabras clave como COLLSCAN y docsExamined para confirmar si se está escaneando una cantidad excesiva de documentos.
-
Registros de auditoría
En la consola de ApsaraDB for MongoDB, vaya a la página para habilitar y consultar el registro de auditoría. Para obtener más información sobre cómo habilitar y usar esta función, consulte Enable the audit log feature.
-
Registros de consultas lentas
ImportanteSolo puede consultar los registros de consultas lentas de los últimos siete días.
Para las instancias adquiridas después del 6 de junio de 2021, primero debe habilitar la función de registro de auditoría y configurar los tipos de operaciones auditadas para incluir admin y slow. Después podrá consultar el registro de consultas lentas. Solo se registran las consultas lentas que ocurren tras habilitar el registro de auditoría.
-
En la consola de ApsaraDB for MongoDB, vaya a la página . Configure los parámetros operationProfiling.mode (modo de consulta lenta) y operationProfiling.slowOpThresholdMs (umbral de consulta lenta) según sus necesidades de negocio.
MongoDB proporciona tres modos de generación de perfiles:
La generación de perfiles está deshabilitada y no se recopilan datos.
La generación de perfiles está habilitada para todas las solicitudes. Los datos de ejecución de todas las solicitudes se registran en la colección system.profile.
La generación de perfiles está habilitada para consultas lentas. Las consultas que superan el umbral especificado se registran en la colección system.profile.
Para obtener más información sobre los parámetros de generación de perfiles, consulte Database Profiler.
En la página , consulte los registros de consultas lentas.
Estrategias de optimización
Optimizar índices
La optimización de índices es la mejor solución para reducir la cantidad de documentos que una consulta individual necesita escanear. En su arquitectura subyacente, ApsaraDB for MongoDB utiliza un diseño de índices similar al de MySQL y ofrece categorías y funciones más completas. Por lo tanto, la mayoría de las políticas de optimización de índices aplicables a MySQL también funcionan en ApsaraDB for MongoDB.
Para obtener más información sobre cómo crear y usar índices, consulte Best practices for creating indexes in ApsaraDB for MongoDB o los siguientes documentos oficiales:
Para obtener más información sobre índices compuestos, consulte Compound Indexes.
Para obtener más información sobre cómo usar índices para ordenar resultados de consultas, consulte Use Indexes to Sort Query Results.
Para obtener más información sobre sugerencias (hints), consulte Cursor Methods y cursor.hint().
Para obtener más información sobre cómo equilibrar la selectividad de un campo de datos con su frecuencia de selección, consulte Create Queries that Ensure Selectivity.
Agregar núcleos de CPU
Si confirma que no hay problemas en las consultas, el uso elevado de CPU se debe a la gran cantidad de solicitudes de servicio y a la alta concurrencia. Puede agregar núcleos de CPU para resolver este problema. En la mayoría de los casos, utilice uno de los siguientes métodos para agregar núcleos de CPU:
Escale verticalmente una sola instancia para gestionar más cargas de trabajo de lectura y escritura.
Configure la división de lectura y escritura a nivel de conjunto de réplicas, o agregue instancias de solo lectura al conjunto de réplicas.
Actualice la instancia problemática a una instancia de clúster fragmentado para lograr un escalado horizontal lineal.
Si la CPU de los nodos de enrutamiento Mongos se agota, agregue nodos Mongos y configure el balanceo de carga para ellos. Para obtener más información sobre el balanceo de carga de nodos Mongos, consulte Load balancing.
Para obtener más información sobre cómo cambiar la configuración de una instancia de ApsaraDB for MongoDB, consulte Change the configuration of a standalone instance, Change replica set instance configurations y Change the configurations of a sharded cluster instance.
Controlar el número de colecciones y la frecuencia de ejecución
Se recomienda agregar índices primero para optimizar los escaneos completos de colección. Si este método ya no resulta útil, controle el volumen de datos de las colecciones y la frecuencia de ejecución desde la aplicación.
Evitar conexiones de corta duración frecuentes
Se recomienda usar conexiones persistentes siempre que sea posible.
Preguntas frecuentes
¿Por qué aumenta el uso de CPU después de actualizar la versión de MongoDB?
Una actualización de versión puede aumentar el uso de CPU cuando cambian los parámetros predeterminados o cuando se modifica un plan de consulta. Siga estos pasos para identificar las operaciones afectadas y optimizarlas.
Ejecute
db.currentOp()enmongoshpara identificar solicitudes de larga duración o anómalas. Si se devuelve unopidanómalo, ejecutedb.killOp(opid)para finalizar esa operación.En la consola de ApsaraDB for MongoDB, vaya a la página CloudDBA > Instance Sessions para analizar las sesiones activas y encontrar solicitudes con un tiempo de ejecución inesperado.
Vaya a la página Log Management > Slow log para identificar escaneos de colecciones o consultas que no utilizan índices. Optimice los índices con base en los resultados del registro de consultas lentas.