¿Cómo soluciono el uso elevado de la CPU en mi instancia de base de datos de Amazon RDS para MySQL o de Aurora compatible con MySQL?

Descripción corta

Hay varios factores que pueden provocar el aumento del uso de la CPU, como las grandes cargas de trabajo iniciadas por los usuarios, las múltiples consultas simultáneas o las transacciones de larga duración.

Para identificar el origen del uso de la CPU en la instancia de base de datos, consulta los siguientes recursos:

• Supervisión mejorada
• Información de rendimiento
• Consultas que detectan la causa del uso de la CPU en la carga de trabajo
• Registros con supervisión activada

Tras identificar la causa, analiza y optimiza la carga de trabajo para reducir el uso de la CPU.

Resolución

Uso de Supervisión mejorada

Supervisión mejorada proporciona una vista a nivel sistema operativo para identificar la causa de una carga elevada de la CPU. Por ejemplo, puedes revisar el promedio de carga, la lista de procesos del sistema operativo y la distribución de la CPU: System (%) o Nice (%).

Usa Supervisión mejorada para comprobar los datos de loadAverageMinute en intervalos de 1, 5 y 15 minutos. Un promedio de carga superior al número de vCPU indica que la instancia está sometida a una carga elevada. Si el promedio de carga es inferior al número de vCPU de la clase de instancia de base de datos, es posible que la limitación de la CPU no provoque la latencia de la aplicación. Para evitar falsos positivos al diagnosticar la causa de la utilización de la CPU, comprueba el promedio de carga.

Por ejemplo, supongamos que tienes una instancia de base de datos que utiliza una clase de instancia db.m5.2xlarge y alcanza el límite de la CPU. La clase de instancia tiene 8 vCPU asociadas. Un promedio de carga superior a 170 indica que la máquina está sometida a una carga elevada durante el periodo de tiempo medido:

Minuto y promedio de carga:

• Quince: 170,25
• Cinco: 391,31
• Uno: 596,74

Utilización de la CPU:

• Usuario (%): 0,71
• Sistema (%): 4,9
• Nice (%): 93,92
• Total (%): 99,97

Nota: Amazon RDS otorga a tu carga de trabajo una prioridad más alta que a otras tareas que se ejecutan en la instancia de base de datos. Para priorizar las tareas relacionadas con la administración, las tareas de carga de trabajo tienen un valor Nice diferente. Como resultado, en la supervisión mejorada, Nice (%) representa la cantidad de CPU que usa tu carga de trabajo en la base de datos.

Tras activar la supervisión mejorada, consulta la lista de procesos del sistema operativo asociada a la instancia de base de datos. Supervisión mejorada muestra un máximo de 100 procesos. Esta lista puede ayudarte a identificar los procesos que más afectan al rendimiento de la CPU y la memoria.

En la sección de la lista de procesos del sistema operativo (SO) de Supervisión mejorada, revisa los procesos del sistema operativo y los procesos de RDS. Estas métricas pueden ayudarte a confirmar si los procesos del sistema operativo o del RDS aumentan el uso de la CPU. O bien, utiliza estas métricas para supervisar el porcentaje de CPU que utilizan los procesos mysqld o aurora. Si el daemon de almacenamiento de Aurora muestra un uso elevado de la CPU en una instancia de Aurora, la instancia tiene una gran carga de trabajo de lectura/escritura. Este uso elevado de la CPU también puede indicar que el tamaño de la instancia podría ser demasiado pequeño para el volumen de almacenamiento y la carga de trabajo actuales. O bien, hay operaciones complejas que se producen en segundo plano.

Para ver la división del uso de la CPU, revisa las métricas de cpuUtilization. Para obtener más información, consulta Supervisión de las métricas del sistema operativo con Supervisión mejorada.

Nota: Si activas Esquema de rendimiento, puedes asignar el ID del subproceso del sistema operativo al ID del proceso solo para la instancia de base de datos de MySQL de RDS. No puedes asignar el ID del subproceso del sistema operativo al ID del proceso de la instancia de base de datos de Aurora MySQL. Para obtener más información, consulta ¿Por qué mi instancia de base de datos de Amazon RDS utiliza memoria de intercambio cuando tengo memoria suficiente?

Uso de Database Insights

Importante: Información de rendimiento llegará al final de su ciclo de vida el 30 de noviembre de 2025. Puedes actualizar al modo avanzado de Database Insights antes del 30 de noviembre de 2025. Si no actualizas, los clústeres de bases de datos que utilizan Información de rendimiento adoptarán de forma predeterminada el modo estándar de Database Insights. Solo el modo avanzado de Database Insights admitirá los planes de ejecución y el análisis bajo demanda. Si los clústeres utilizan el modo estándar de forma predeterminada, es posible que no puedas usar estas características en la consola. Para activar el modo avanzado, consulta Activación del modo avanzado de Database Insights para Amazon RDS. Consulta también Activación del modo avanzado de Database Insights para Amazon Aurora.

Puedes usar Database Insights para identificar las consultas que se ejecutan en la instancia de base de datos y provocan un uso elevado de la CPU.

En primer lugar, activa Database Insights en tu instancia de MySQL. A continuación, utiliza Database Insights para optimizar tu carga de trabajo. También puedes colaborar con el administrador de la base de datos para identificar la causa raíz del problema.

Para obtener información sobre la compatibilidad de motores, regiones de AWS y clases de instancia, consulta Compatibilidad con el motor de base de datos de Aurora, la región y la clase de instancia para Database Insights. Consulta también Compatibilidad con el motor de base de datos de Amazon RDS, la región y la clase de instancia para Database Insights.

Uso de consultas para detectar la causa del uso de la CPU en la carga de trabajo

Antes de poder optimizar la carga de trabajo, debes identificar la consulta problemática. Para identificar la causa raíz del uso de la CPU, ejecuta las siguientes consultas cuando se produzca un problema de CPU alta.

Para ver los subprocesos que se ejecutan en tu instancia de MySQL, ejecuta el comando SHOW FULL PROCESSLIST:

SHOW FULL PROCESSLIST;

Nota: Usa la consulta SHOW PROCESSLIST como usuario principal del sistema. Debes tener permisos de administración del servidor MySQL PROCESS para ver todos los subprocesos que se ejecutan en una instancia de MySQL. Sin permisos de administrador, SHOW PROCESSLIST muestra solo los subprocesos asociados a la cuenta de MySQL que utilizas.

A veces, el mismo conjunto de instrucciones puede seguir procesándose sin completarse. Cuando esto ocurre, las instrucciones subsiguientes deben esperar a que termine la primera serie de instrucciones. Esto se debe a que el bloqueo de la fila de InnoDB puede estar actualizando las mismas filas. Para obtener más información, consulta SHOW PROCESSLIST statement (Instrucción SHOW PROCESSLIST) en el sitio web de MySQL.

La tabla INNODB_TRX proporciona información sobre todas las transacciones de InnoDB que se están procesando y que no son transacciones de solo lectura. Para ver la tabla INNODB_TRX, ejecuta la siguiente consulta:

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

La tabla INNODB_LOCKS proporciona información sobre los bloqueos que una transacción de InnoDB solicita pero no recibe. Para ver la tabla INNODB_LOCKS, ejecuta la siguiente consulta:

MySQL 5.7 o anterior:

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

MySQL 8.0:

SELECT * FROM performance_schema.data_locks;

Para obtener más información, consulta la sección de MySQL 5.7 The INFORMATION_SCHEMA.INNODB_LOCKS table (Tabla INFORMATION_SCHEMA.INNODB_LOCKS) y la sección de MySQL 8.0 The data_locks table (Tabla data_locks) en el sitio web de MySQL.

La tabla INNODB_LOCK_WAITS proporciona una o más filas para cada transacción de InnoDB bloqueada. Para ver la tabla INNODB_LOCKS_WAITS, usa la siguiente consulta.

MySQL 5.7 o anterior:

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

MySQL 8.0:

SELECT * FROM performance_schema.data_lock_waits;

Puedes usar una consulta similar a la siguiente para ver las transacciones que están en espera y las transacciones que bloquean las transacciones en espera:

MySQL 5.7 o anterior:

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,  
  r.trx_query waiting_query,  
  b.trx_id blocking_trx_id,  
  b.trx_mysql_thread_id blocking_thread,  
  b.trx_query blocking_query  
FROM       information_schema.innodb_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_trx_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_trx_id;

MySQL 8.0:

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,  
  r.trx_query waiting_query,  
  b.trx_id blocking_trx_id,  
  b.trx_mysql_thread_id blocking_thread,  
  b.trx_query blocking_query  
FROM       performance_schema.data_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_engine_transaction_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_engine_transaction_id;

Para interpretar el resultado de esta consulta, consulta la sección de MySQL 8.0 Using InnoDB transaction and locking information (Uso de la información de transacciones y bloqueos de InnoDB) en el sitio web de MySQL.

Para obtener información del monitor estándar de InnoDB sobre el estado del motor de almacenamiento InnoDB, ejecuta la siguiente consulta:

SHOW ENGINE INNODB STATUS;

Para obtener más información, consulta la sección de MySQL 8.0 SHOW ENGINE Statement (Instrucción SHOW ENGINE) en el sitio web de MySQL.

Para ver el estado del servidor, usa el siguiente comando.

SHOW GLOBAL STATUS;

Para obtener más información, consulta la sección de MySQL 8.0 SHOW STATUS statement (Instrucción SHOW STATUS) en el sitio web de MySQL.

Para comprobar la longitud de la lista del historial (HLL), ejecuta el siguiente comando:

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

Si tu carga de trabajo requiere varias transacciones abiertas o de ejecución prolongada, es posible que tu base de datos tenga un valor de HLL alto. Además, si los subprocesos de purga no pueden mantenerse al día con los cambios en la base de datos, es posible que tengas un valor de HLL alto. Un valor de HLL alto provoca un mayor uso de recursos y un rendimiento lento e inconsistente de las instrucciones SELECT.

En una instancia de escritura de Aurora MySQL, utiliza la métrica RollbackSegmentHistoryListLength de CloudWatch para supervisar tu HLL.

Si la instancia tiene un valor de HLL alto, revisa tu instrucción SQL. Este problema se produce cuando se aplica START TRANSACTION y no hay ningún COMMIT. Como el subproceso entró en estado de suspensión, no puedes ver la instrucción SQL anterior.

Para resolver este problema, ejecuta el siguiente comando.

SELECT event_id, current_schema, sql_text, lock_time
 FROM performance_schema.events_statements_history
 WHERE thread_id=<thread_id>  
 ORDER BY event_id DESC;

Análisis de los registros y activación de la supervisión

Analiza el registro de consultas generales de MySQL para ver qué está haciendo mysqld en un momento específico. También puedes ver las consultas que se ejecutan en tu instancia en un momento específico, como la información sobre cuándo se conectan o desconectan los clientes. Para obtener más información, consulta The General Query Log (Registro de consultas generales) en el sitio web de MySQL.

Importante: Cuando se activa el registro de consultas generales durante periodos prolongados, los registros consumen almacenamiento y pueden aumentar la sobrecarga de rendimiento.

Analiza los registros de consultas lentas de MySQL para encontrar consultas que tarden más en ejecutarse que los segundos que has establecido para long_query_time. También puedes revisar la carga de trabajo y analizar las consultas para mejorar el rendimiento y el consumo de memoria. Para obtener más información, consulta 7.4.5 The slow query log (7.4.5 Registro de consultas lentas) en el sitio web de MySQL.

Nota: Cuando utilices el registro de consultas lentas o el registro de consultas generales, se recomienda establecer el parámetro log_output en FILE.

Utiliza el complemento de auditoría de MariaDB para auditar la actividad de la base de datos en Amazon RDS para MySQL o Amazon RDS para MariaDB. Por ejemplo, realiza un seguimiento de los usuarios que inician sesión en la base de datos o de las consultas que se ejecutan en la base de datos.

Si usas Aurora compatible con MySQL, puedes usar la auditoría avanzada. La auditoría avanzada proporciona un mayor control sobre los tipos de consultas que deseas registrar y reduce la sobrecarga de registro.

Utiliza el parámetro innodb_print_all_deadlocks para comprobar si hay interbloqueos y bloqueos de recursos. Puedes usar este parámetro para registrar información sobre los interbloqueos en las transacciones de los usuarios de InnoDB en el registro de errores de MySQL. Para obtener más información, consulta innodb_print_all_deadlocks en el sitio web de MySQL.

Análisis y optimización de la carga de trabajo elevada de la CPU

Tras identificar la consulta que aumenta el uso de la CPU, optimiza la carga de trabajo para reducir el consumo de la CPU.

Si ves una consulta que no es necesaria para la carga de trabajo, ejecuta el siguiente comando para finalizar la conexión:

CALL mysql.rds_kill(processID);

Importante: Cuando finalizas las escrituras del lenguaje de manipulación de datos (DML) en una instancia, se restaura la transacción interrumpida. Restaurar las actualizaciones puede llevar mucho tiempo. Si la consulta se ejecuta durante mucho tiempo, trabaja con el administrador de bases de datos para comprobar si puedes detener la consulta.

Para buscar el ID de proceso de una consulta, ejecuta el comando SHOW FULL PROCESSLIST.

Si no quieres finalizar la consulta, usa EXPLAIN para optimizarla. EXPLAIN muestra los pasos individuales que se deben seguir cuando se procesa una consulta. Para obtener más información, consulta Optimizing queries with EXPLAIN (Optimización de consultas con EXPLAIN) en el sitio web de MySQL.

Para revisar los detalles del perfil, activa el perfilado. El comando SHOW PROFILE indica el uso de recursos de las instrucciones que se ejecutan durante la sesión actual. Para obtener más información, consulta SHOW PROFILE statement (Instrucción SHOW PROFILE) en el sitio web de MySQL.

Para ver y optimizar las estadísticas de la tabla, utiliza la consulta ANALYZE TABLE. Para obtener más información, consulta ANALYZE TABLE statement (Instrucción ANALYZE TABLE) en el sitio web de MySQL.

Información relacionada

Ajuste de Aurora MySQL con eventos de espera

¿Cómo puedo activar y supervisar los registros de una instancia de base de datos de Amazon RDS para MySQL?

Amazon CloudWatch Database Insights applied in real scenarios (Amazon CloudWatch Database Insights aplicado en escenarios reales)