:High CPU utilization in PolarDB for MySQL

A medida que crece su negocio, la especificación actual del clúster puede resultar insuficiente. Las gráficas de rendimiento suelen mostrar una métrica, como QPS o IOPS, con una tendencia ascendente similar a la del uso de CPU

Si la CPU es el cuello de botella, es probable que la especificación del clúster sea insuficiente para el tráfico de su negocio. Resuélvalo agregando un nodo de solo lectura al clúster de bases de datos o aumentando la especificación del clúster.

• Si su carga de trabajo consiste principalmente en solicitudes de lectura, puede agregar un nodo de solo lectura para escalar horizontalmente el clúster y distribuir el tráfico de lectura. Para obtener más información, consulte Add or remove nodes.

• Si su carga de trabajo consiste principalmente en solicitudes de escritura, agregar un nodo de solo lectura no mejorará el rendimiento. En este caso, debe manually scale up la especificación del clúster; por ejemplo, actualizar de una especificación de 4 núcleos a una de 8 núcleos.

Consultas lentas

El alto uso de CPU suele deberse a instrucciones SQL ineficientes que generan consultas lentas y una acumulación de hilos activos. Sin embargo, primero debe determinar si las consultas lentas son la causa raíz del alto uso de CPU o si otro cuello de botella de recursos está ralentizando las consultas y aumentando indirectamente el uso de CPU.

Consulte las consultas lentas en PolarDB console desde Diagnostics and Optimization > Slow SQL. En la pestaña Slow Log Details, si el valor de Scanned Rows es significativamente mayor que el valor de Returned Rows, esto indica que las consultas lentas están causando el alto uso de CPU.

Las consultas TP implican muy pocas lecturas y escrituras de datos. Si una consulta analiza una gran cantidad de datos, es muy probable que falte un índice. Por ejemplo, si una consulta de la lista de consultas lentas muestra que se analizaron más de 10,000 filas pero solo se devolvió una fila, es un indicio claro de que falta un índice en la columna name.

SELECT * FROM table1 WHERE name='testname';

Para comprobar si existe un índice en la columna name, use la instrucción que aparece a continuación.

SHOW index FROM table1;

• Si la columna name no tiene un índice, puede agregar un índice con la instrucción que aparece a continuación para eliminar las consultas lentas causadas por estos análisis de datos a gran escala.

  ALTER TABLE table1 ADD KEY ix_name (name);

• Si la columna name tiene un índice, use la instrucción que aparece a continuación; consulte el plan de ejecución de la instrucción SQL y confirme si se usa el índice correcto.

  EXPLAIN SELECT * FROM table1 WHERE name='testname';

  Si observa que existe un índice en la columna name pero no se usa, esto puede deberse a que las estadísticas son imprecisas y generaron un plan de ejecución incorrecto. Ejecute la instrucción que aparece a continuación para regenerar las estadísticas de la tabla y corregir el plan.

  ANALYZE TABLE table1;

  Una vez que el comando finalice, compruebe de nuevo el plan de ejecución y confirme que ahora se usa el índice correcto:

  EXPLAIN SELECT * FROM table1 WHERE name='testname';

Pregunta frecuente: ¿Por qué instrucciones SQL y volúmenes de análisis idénticos producen un uso de CPU significativamente distinto en diferentes clústeres de PolarDB?

La saturación de CPU suele deberse a solicitudes lentas. Aunque el texto SQL y el volumen teórico de análisis parezcan idénticos en diferentes clústeres, el comportamiento real de ejecución puede variar. Investigue las áreas a continuación:

1. Compare los detalles reales del registro de consultas lentas: Revise y compare los registros de consultas lentas de ambos clústeres; confirme si difieren las filas analizadas reales, las filas devueltas y el tiempo de ejecución. La misma instrucción SQL puede tener diferentes planes de ejecución o encontrar distribuciones de datos distintas en distintos clústeres.

2. Compruebe las diferencias de arquitectura de los clústeres: Compruebe si el clúster con carga alta tiene menos nodos de solo lectura que el clúster con carga baja. Si las solicitudes de lectura no se descargan en nodos de solo lectura, el nodo principal recibe una carga mayor, lo que produce un mayor uso de CPU.

3. Recomendaciones de optimización: Para evitar la saturación de CPU, céntrese en optimizar las solicitudes lentas y reducir el número real de filas que analizan las instrucciones SQL, en lugar de comprobar únicamente si el texto SQL es idéntico.

Alto número de hilos activos

Un alto número de hilos activos siempre aumenta el uso de CPU. En MySQL, cada núcleo de CPU solo puede procesar una solicitud a la vez. Por ejemplo, un clúster de 16 núcleos puede manejar un máximo de 16 solicitudes simultáneas a nivel del kernel, lo cual es distinto de la concurrencia a nivel de aplicación. Consulte la información de sesión en PolarDB console desde Diagnostics and Optimization > One-click diagnosis > Sessions.

Si descarta las consultas lentas como causa de fallas en el procesamiento de solicitudes, una acumulación de hilos activos normalmente se debe a un aumento del tráfico de producción. Puede view the performance curves para comprobarlo. Si las tendencias generales de tráfico y solicitudes coinciden con la tendencia de acumulación de hilos activos, esto indica que los recursos del clúster han llegado a su límite. Para resolver este problema, debe agregar nodos de solo lectura al clúster de bases de datos o aumentar la especificación del clúster.

Cuando el número de hilos activos alcanza un punto crítico, puede producirse contención de CPU, lo que genera numerosos bloqueos mutex en el kernel. Las gráficas de rendimiento suelen mostrar alto uso de CPU, alto número de hilos activos y IOPS o QPS bajos. Otra causa es un aumento repentino del tráfico, donde una alta tasa de conexiones nuevas también provoca contención de CPU y acumulación de solicitudes. Con frecuencia puede mitigar este problema mediante la habilitación de la función thread pool del clúster para control de flujo. Si el número de hilos activos se reduce, compruebe si aún hay tareas acumuladas en el lado de la aplicación. Si la carga de CPU y el número de hilos activos siguen siendo altos, considere también aumentar la especificación del clúster.

Una tormenta de conexiones de frontend también puede causar un pico de tráfico instantáneo en el clúster. Se trata de tráfico anormal, a menudo causado por rastreadores web. Puede usar la limitación de SQL para rechazar solicitudes. Para obtener más información, consulte Session Management.

Configuración inadecuada del kernel

Los parámetros predeterminados de una instancia MySQL autogestionada se configuran para escenarios de uso general y pueden no ser óptimos para todas las cargas de trabajo; es posible que requieran ajustes finos. Algunos problemas pueden no aparecer en las primeras etapas de una aplicación, cuando el volumen de datos es pequeño, pero surgen a medida que los datos crecen con el tiempo y se cumplen ciertas condiciones.

La contención de memoria es un problema común. En la arquitectura de MySQL, la memoria se usa principalmente para caché de datos. Las áreas de memoria más usadas son buffer pool y innodb_adaptive_hash_index. El área de caché de todo el sistema de base de datos es donde los datos se intercambian con más frecuencia. Si hay memoria insuficiente o contención de páginas de memoria, pueden acumularse diversas excepciones y consultas lentas. Un síntoma típico es un pico repentino del uso de CPU hasta su nivel máximo, acompañado de consultas lentas. Si al investigar se revela que el problema no es un índice faltante, el problema puede estar en el sistema de memoria.

Por ejemplo, cuando se ejecuta una operación truncate table, MySQL recorre el buffer pool para expulsar todas las páginas de datos de la tabla afectada por la operación truncate. En un clúster de gran escala, si innodb_buffer_pool_instances se establece en 1 y la concurrencia es relativamente alta, pueden producirse problemas de contención. Este problema puede detectarse temprano en el ciclo de vida del servicio y, por lo general, puede evitarse alineando el valor de innodb_buffer_pool_instances con el número de núcleos de CPU y dividiendo el buffer pool en segmentos.

Otro escenario es la contención por innodb_adaptive_hash_index. Un síntoma claro es una gran cantidad de esperas de hash0hash.cc.

SHOW ENGINE innodb STATUS;

En la sección AHI de la salida, observará una distribución desigual significativa de los datos.

insert 0, delete mark 0, delete 0
Hash table size 25499819, node heap has 20720 buffer(s)
Hash table size 25499819, node heap has 25111 buffer(s)
Hash table size 25499819, node heap has 23884 buffer(s)
Hash table size 25499819, node heap has 16835 buffer(s)
Hash table size 25499819, node heap has 23132 buffer(s)
Hash table size 25499819, node heap has 189284 buffer(s)
Hash table size 25499819, node heap has 38864 buffer(s)
Hash table size 25499819, node heap has 49094 buffer(s)
5469.32 hash searches/s, 5282.36 non-hash searches/s

Para este tipo de problema, deshabilite el parámetro innodb_adaptive_hash_index; esto deshabilita la función AHI. Los datos muestran que, en escenarios mixtos de lectura y escritura, AHI puede tener un impacto negativo en el rendimiento, pero deshabilitarlo no afecta significativamente el negocio en general.

Anomalía de recursos de memoria que causa alto uso de CPU o conmutación principal/en espera

Las anomalías de recursos de memoria pueden causar indirectamente alto uso de CPU, caídas de instancias o conmutaciones principal/en espera (alta disponibilidad). Los escenarios a continuación cubren causas comunes, entre ellas memoria al 100%, eventos de memoria agotada (OOM), caídas, conmutaciones principal/en espera, eventos de alta disponibilidad, instrucciones preparadas sin cerrar, instrucciones SQL largas, disparadores y problemas del analizador de consultas.

Escenario 1: OOM (memoria agotada) que provoca una caída de la instancia

Causa: Las conexiones excesivas (una gran cantidad de conexiones inactivas) y las instrucciones preparadas que no se cierran a tiempo provocan un uso excesivo de memoria; finalmente, esto desencadena un evento OOM y causa la caída de la instancia.

Soluciones:

• En el lado de la aplicación, recicle oportunamente las conexiones inactivas.

• Cierre a tiempo las instrucciones preparadas e investigue la causa raíz de los inicios simultáneos de instrucciones preparadas.

• Actualice a una versión secundaria más reciente del motor durante horas de baja actividad para aprovechar las optimizaciones de memoria a nivel del kernel.

• Intente reducir el valor del parámetro innodb_buffer_pool_size y observe si el problema mejora.

Escenario 2: Concentración de memoria del analizador de consultas que provoca crecimiento sostenido de memoria o conmutación principal/en espera

Causa: Las instrucciones SQL largas y los disparadores grandes provocan un alto consumo de memoria del analizador. Tenga en cuenta los puntos a continuación:

• Incluso si una instrucción SQL específica se ha optimizado o no se dirige al nodo de escritura, otras instrucciones SQL largas o disparadores aún pueden desencadenar el problema.

• Las operaciones DML deben ejecutarse en el nodo principal, independientemente de cualquier configuración de separación de lectura/escritura.

Soluciones:

• Divida las instrucciones SQL largas en varias instrucciones más cortas.

• Optimice los disparadores o reduzca su longitud.

• Controle la longitud del SQL en el nivel de la aplicación.

• Si es necesario, actualice la especificación de la instancia o ajuste el parámetro innodb_buffer_pool_size.

Escenario 3: SQL de análisis de gran volumen que provoca que la memoria llegue al 100% y desencadena una conmutación principal/en espera (no se refleja en los informes de diagnóstico)

Causa: Las instrucciones SQL con análisis de gran volumen, como consultas con condiciones complejas o agregaciones COUNT, consumen grandes cantidades de memoria. Estas instrucciones pueden no aparecer en los informes de diagnóstico, lo que dificulta su detección.

Soluciones:

• Analice el registro de consultas lentas para identificar instrucciones SQL específicas con análisis de gran volumen.

• Optimice las instrucciones SQL identificadas agregando índices adecuados o reescribiendo las consultas.

Errores del sistema

Los errores del sistema son una causa relativamente poco común de problemas de alto uso de CPU. Ejemplos de versiones anteriores incluyen bloqueos de procesos y análisis completos de tablas causados por estadísticas de tabla restablecidas a cero. A medida que evoluciona el producto, los problemas de CPU causados por errores del sistema son menos frecuentes. Sin embargo, la solución de estos problemas a menudo requiere información detallada a nivel del kernel y puede ser difícil resolverlos por su cuenta. Le recomendamos contact us para obtener asistencia técnica.