Todos los productos
Search

Este producto

    ApsaraDB RDS:High CPU utilization on ApsaraDB RDS for MySQL or MariaDB instances

    Centro de documentos

    ApsaraDB RDS:High CPU utilization on ApsaraDB RDS for MySQL or MariaDB instances

    Última actualización: Sep 17, 2026

    Descripción del problema

    El uso de CPU de su instancia de ApsaraDB RDS for MySQL o MariaDB es elevado y, en ocasiones, alcanza el 100 %.

    Causas

    Cuando una aplicación envía una consulta o modifica datos, el sistema ejecuta muchas operaciones de lectura lógica. Estas operaciones implican acceder a numerosas filas de datos en una tabla. Después, el sistema consume recursos significativos de CPU para mantener la coherencia de los datos entre el almacenamiento y la memoria. Este tema explica dos causas comunes del uso de CPU al 100 % y sus soluciones: la alta carga de la aplicación, medida en consultas por segundo (QPS), y el alto costo de las consultas debido a sentencias SQL lentas. En MySQL, este consumo excesivo suele originarse por sentencias SQL lentas que acceden a muchas filas de datos, lo cual incrementa el costo de la consulta.

    Nota

    Este tema no aborda el alto uso de CPU provocado por conflictos de bloqueo de filas, esperas de bloqueo o tareas en segundo plano. Estos problemas ocurren con poca frecuencia.

    • Alta carga de la aplicación (QPS elevado):

      • Características: La instancia presenta un QPS elevado. Las consultas son simples y eficientes. Existe poco margen de optimización.

      • Síntomas: No se registran consultas lentas, o bien estas no son la causa principal. Las curvas de QPS y de uso de CPU coinciden.

      • Escenarios comunes: Este problema es frecuente en sistemas de procesamiento de transacciones en línea (OLTP) optimizados, como los sistemas de pedidos. También aparece en aplicaciones web populares con altas tasas de lectura y en herramientas de pruebas de estrés de terceros, como Sysbench.

    • Alto costo de consultas por sentencias SQL lentas (se accede a muchas filas de datos):

      • Características: La instancia tiene un QPS bajo. La ejecución de las consultas es ineficiente y requiere examinar grandes volúmenes de datos de la tabla. Hay un margen considerable de optimización.

      • Síntomas: Existen consultas lentas. Las curvas de QPS y de uso de CPU no coinciden.

      • Análisis de la causa: Las consultas ineficientes necesitan acceder a grandes cantidades de datos para obtener los resultados esperados. Esto genera un promedio alto de E/S lógicas. Como consecuencia, el uso de CPU puede ser elevado incluso cuando el QPS es bajo, por ejemplo, en un sitio web con poco tráfico.

    Soluciones

    Elija una solución según su situación específica.

    Alta carga de la aplicación (QPS elevado)

    Si el alto uso de CPU se debe a una carga elevada de la aplicación, existe poco margen para optimizar el código SQL. Resuelva el problema ajustando la arquitectura de la aplicación o el tipo de instancia. Considere los siguientes métodos:

    • Actualice el tipo de instancia para agregar más recursos de CPU. Para obtener más información, consulte Change instance configurations.

    • Agregue instancias de solo lectura. Transfiera a estas instancias las consultas que no sean sensibles a la coherencia de los datos, como las búsquedas de categorías de productos u horarios de trenes. De esta forma se reduce la carga en la instancia principal. Para obtener más información, consulte Create an ApsaraDB RDS for MySQL read-only instance.

    • Utilice PolarDB-X, una base de datos distribuida nativa de la nube de Alibaba Cloud. Esta herramienta aplica fragmentación (sharding) automáticamente para distribuir la carga de consultas entre varias instancias de RDS.

    • Use Alibaba Cloud Memcache o Tair (compatible con Redis OSS). Recupere del caché los resultados de las consultas frecuentes para reducir la carga en la instancia de RDS.

    • En aplicaciones que consultan datos relativamente estáticos, repiten mucho las mismas consultas y generan conjuntos de resultados menores a 1 MB, considere habilitar el caché de consultas.

      Nota

      Compruebe si habilitar el caché de consultas beneficia a su aplicación. Para conocer más sobre la configuración, consulte Set and use the query cache for ApsaraDB RDS for MySQL.

    • Archive periódicamente los datos históricos. Use la fragmentación o el particionamiento para disminuir la cantidad de datos que consultan las solicitudes. Optimice las consultas para reducir el costo de ejecución y mejorar la escalabilidad de la aplicación.

    Alto costo de consultas por sentencias SQL lentas

    Para resolver este problema, localice las consultas ineficientes, optimice su eficiencia de ejecución y reduzca su costo.

    1. Localice las consultas ineficientes de las siguientes maneras:

      • Ejecute la siguiente sentencia SQL para consultar las consultas que se están procesando actualmente.

        show processlist;
show full processlist;

        El sistema muestra un resultado similar al siguiente:

        mysql> show processlist;
+----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
| Id       | User  | Host              | db      | Command | Time  | State        | Info                                         |
+----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
|101031643 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|117731567 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|134298793 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|134384670 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   |     0 | Init         | show processlist                             |
|234891284 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|235125098 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|235200576 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|235633985 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|235887773 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|251990394 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
|252662718 | jacky | xxx.xxx.xxx.xx:xx | my_test | Query   | 10760 | Sending data | select b.* from perf_test_no_idx_01 a, ...   |
+----------+-------+-------------------+---------+---------+-------+--------------+----------------------------------------------+
11 rows in set (0.00 sec)

        Las sesiones de consulta que se ejecutan durante mucho tiempo y presentan el estado Sending data, Copying to tmp table, Copying to tmp table on disk, Sorting result o Using filesort podrían tener problemas de rendimiento.

        • En escenarios donde un QPS elevado provoca un alto uso de CPU, las consultas suelen ejecutarse rápido. Por ello, capturarlas con el comando show processlist; o al consultar las sesiones de la instancia resulta difícil. En este caso, ejecute la siguiente sentencia SQL:

          explain [$SQL]
          Nota

          [$SQL] es la consulta SQL que presenta problemas de rendimiento.

        • Puede ejecutar un comando como kill [$ID]; para finalizar una sesión de larga duración. Para obtener más información sobre cómo terminar sesiones, consulte How to stop sessions on an ApsaraDB RDS for MySQL instance.

          Nota

          [$ID] es el identificador de sesión correspondiente a la consulta.

      • Consulte las consultas en ejecución mediante Database Autonomy Service (DAS):

        1. Inicie sesión en la consola de DAS.

        2. En el panel de navegación izquierdo, haga clic en Intelligent O&M Center > Instance Monitoring.

        3. Busque la instancia de destino y haga clic en su ID para abrir la página de detalles.

        4. En el panel de navegación izquierdo, haga clic en Instance Sessions.

        5. Haga clic en el texto de la consulta dentro de la columna SQL para mostrar la consulta completa y su plan de ejecución.

    2. Una vez identificadas las consultas que requieren optimización, utilice SQL Diagnostics en la consola de DMS para obtener sugerencias. El informe de diagnóstico también sirve para solucionar problemas históricos de alto uso de CPU:

      1. Inicie sesión en la instancia desde la consola de DMS. Para obtener más información, consulte Log on to a database instance.

      2. En la parte superior de la página, haga clic en SQL Window y seleccione la base de datos de destino.

      3. Pegue la consulta en la ventana SQL y haga clic en SQL Diagnostics para obtener sugerencias de optimización.

    3. Aplique las sugerencias de optimización según sea necesario. Por ejemplo, agregar un índice reduce significativamente el costo de ejecución de las consultas.

    Más información

    Funciones para solucionar problemas de rendimiento

    Data Management (DMS) ofrece varias funciones que le ayudan a diagnosticar y resolver problemas de rendimiento en las instancias. El informe de diagnóstico es la mejor herramienta para solucionar estos inconvenientes en instancias de MySQL y MariaDB. Sin importar la causa, revise primero dicho informe. Preste especial atención a las secciones de optimización de SQL, lista de sesiones y resumen de SQL lento.

    Principios para evitar el uso de CPU al 100 %

    Siga estos principios para evitar que el uso de CPU alcance el 100 %:

    • Configure alertas de uso de CPU para asegurar que la instancia mantenga un margen suficiente de este recurso.

    • Durante el diseño y desarrollo de la aplicación, tome en cuenta la optimización de consultas. Siga los principios generales de optimización de MySQL para reducir las E/S lógicas y mejorar la escalabilidad de la aplicación.

    • Antes de poner en producción una nueva función o módulo, ejecute pruebas de estrés con datos reales .

    • Antes de poner en producción una nueva función o módulo, ejecute pruebas de regresión con datos reales.

    Algoritmo de recursos del sistema

    El siguiente modelo simplificado explica la relación entre los recursos del sistema, el costo de ejecución de las sentencias SQL y las consultas por segundo (QPS):

    • Condición: El modelo de la aplicación es constante, es decir, la aplicación no se modifica.

    • avg_lgc_io: El promedio de E/S lógicas necesarias para ejecutar cada consulta.

    • total_lgc_io: El total de E/S lógicas que los recursos de CPU de la instancia pueden procesar por unidad de tiempo.

    • Fórmula: total_lgc_io = avg_lgc_io × QPS. Esto significa que Total de recursos de CPU por unidad de tiempo = Promedio de E/S lógicas por consulta × Número de consultas por unidad de tiempo.

    Referencias

    Resolve high CPU utilization on an ApsaraDB RDS for MySQL instance using the autonomy service

    Versiones aplicables

    • ApsaraDB RDS for MySQL

    • ApsaraDB RDS for MariaDB