Cuando el uso de CPU aumenta repentinamente en producción, identificar los métodos exactos responsables resulta difícil si solo se revisan las métricas. Application Real-Time Monitoring Service (ARMS) perfila continuamente los hilos activos de CPU mediante la captura periódica de instantáneas de pila a nivel de método. Estas instantáneas se agrupan en gráficos de flamas y estadísticas por método, lo que permite detectar qué rutas de código consumen más ciclos de CPU.
Habilitar el diagnóstico de CPU añade una sobrecarga aproximada del 5 % de CPU. Asegúrese de que sus instancias tengan capacidad suficiente antes de activarlo.
Funcionamiento de los gráficos de flamas
ARMS agrupa las instantáneas de pila muestreadas en un gráfico de flamas que codifica dos dimensiones:
|
Dimensión |
Significado |
Cómo interpretarla |
|
Ancho (eje X) |
Proporción del tiempo total de CPU que consumió un método |
Los cuadros más anchos indican mayor tiempo de CPU |
|
Profundidad (eje Y) |
Jerarquía de llamadas: la parte inferior es el punto de entrada y la superior es el método hoja |
Revise la parte superior del gráfico para ver los métodos donde realmente se gastan los ciclos de CPU |
La posición horizontal no representa el avance del tiempo. Dos métodos colocados uno junto al otro no necesariamente se ejecutaron de forma secuencial.
Tiempo propio frente a tiempo total
Dos métricas ayudan a distinguir entre los métodos costosos por sí mismos y aquellos que contribuyen al uso elevado de CPU a través de sus métodos secundarios:
|
Métrica |
Definición |
Cuándo usarla |
|
Self |
Tiempo o recursos que consume un método dentro de la pila, sin contar el tiempo o los recursos que consumen los métodos secundarios |
Para encontrar métodos costosos por sí mismos |
|
Total |
Tiempo o recursos que consume un método, incluido el tiempo o los recursos que consumen todos los métodos secundarios |
Para encontrar las rutas de llamada que aportan más tiempo total de CPU |
El tiempo Self equivale al tiempo Total menos la suma de los tiempos Total de los métodos secundarios. Por ejemplo, si un método muestra 309 ms en Total y su único método secundario muestra 112 ms en Total, el tiempo Self del método primario es de 197 ms (309 - 112).
Habilitación del diagnóstico de CPU
Inicie sesión en ARMS console. En el panel de navegación izquierdo, elija Application Monitoring > Application List.
-
En la página Application List, seleccione una región en la barra de navegación superior y haga clic en el nombre de la aplicación.
Los iconos de la columna Language indican el lenguaje de la aplicación:
Java 
Go 
Python Un guion ( - ) indica que la aplicación se monitorea mediante Managed Service for OpenTelemetry. En el panel de navegación izquierdo, haga clic en Application Settings. Haga clic en la pestaña Custom Configuration.
En la sección Continuous profiling, active Main switch y CPU hotspot. Después, especifique la dirección IP de una instancia de la aplicación o los bloques CIDR de varias instancias.
Haga clic en Save.
El cambio surte efecto de inmediato, sin necesidad de reiniciar la aplicación.
Identificación del método causante
A continuación se utiliza un método de Java que espera activamente durante 500 milisegundos para simular un consumo sostenido de CPU:
public class CPUPressure {
// Busy-wait loop that holds the CPU for 500 ms per call
public void runBusiness() {
long start = System.currentTimeMillis(), period = 0;
while (period <= 500L) {
period = System.currentTimeMillis() - start;
}
}
}Paso 1: Abrir la vista de perfilado
Inicie sesión en ARMS console. En el panel de navegación izquierdo, elija Application Monitoring > Application List.
-
En la página Application List, seleccione una región en la barra de navegación superior y haga clic en el nombre de la aplicación.
Los iconos de la columna Language indican el lenguaje de la aplicación:
Java Go Python Un guion ( - ) indica que la aplicación se monitorea mediante Managed Service for OpenTelemetry. En el panel de navegación izquierdo, haga clic en Continuous profiling. Seleccione la instancia de destino y un intervalo de tiempo.
-
En la pestaña Single View, consulte los datos y revise los resultados de agregación.
Hay tres tipos de perfilado disponibles: CPU Time: núcleos de CPU que consume cada método.Allocated Memory: bytes de memoria asignados.Allocations: número de llamadas de asignación de memoria, útil para detectar métodos que asignan memoria con frecuencia.
Paso 2: Localizar el método costoso
-
Haga clic en Aggregation & Analysis. Establezca Profiling Type en CPU Time. El panel izquierdo enumera todos los métodos presentes en las pilas de llamadas muestreadas. El panel derecho muestra el gráfico de flamas.
-
Ordene la columna Self de forma ascendente. Busque y haga clic en el método con el valor Self más alto. En este ejemplo,
java.lang.System.currentTimeMillis()aparece en la parte superior. Al hacer clic en él, se resalta el cuadro correspondiente en el gráfico de flamas.
Confirme en el gráfico de flamas que
currentTimeMillis()tiene el cuadro más ancho en la parte superior de la pila. Esto significa que consumió la mayor cantidad de tiempo o recursos Self.
Paso 3: Rastrear hasta el código de la aplicación
Dado que currentTimeMillis() es un método de la biblioteca JDK, baje un nivel en la pila de llamadas para encontrar el método de la aplicación que lo invoca: com.alibaba.cloud.pressure.memory.CPUPressure.runBusiness().
Este método consumió 28.63 segundos en una ventana de 1 minuto, lo que representa el 91.44 % del tiempo total de CPU. Este comportamiento coincide con lo esperado, ya que runBusiness() espera activamente durante 500 ms en cada invocación y domina el uso de CPU bajo carga.