Inicio / Notas técnicas / Resolución de problemas de CPU y memoria del router

CPU y memoria del router demasiado altos: de display health a los flame graphs

Un router AR con la CPU disparada, o con una fuga lenta de memoria, no falla como un switch luchando contra una tormenta TC o un bucle MSTP — normalmente es un solo proceso, un solo hilo, o un handle de memoria que no deja de crecer. Esta es la escalera de comandos que lo encuentra: display health para la línea base, display cpu-usage top para el proceso culpable, y — nuevo desde V600R024C10 — un flame graph real para el caso en que el nombre del proceso por sí solo no lo explica.

Por Yuwen Zhang (Atlas), fundador de AtlasCommTech — 13 años de despliegues de redes de operadores y empresariales · Actualizado en julio de 2026

Por qué esta no es la guía de un switch

El plano de control de un router se satura por razones distintas a las de un switch — perseguir al culpable equivocado desperdicia toda la tarde.

Si el equipo frente a usted es un switch y la CPU está saturada, muy a menudo se trata de una tormenta TC o un bucle MSTP recalculando la topología — vea Switch CPU Utilization High: Finding What's Eating the Control Plane para ese camino. Las quejas de CPU y memoria de un router AR suelen tener otra forma: un proceso que calienta silenciosamente, un hilo atascado en un bucle, o un handle de memoria interno a un proceso que no deja de crecer y nunca lo devuelve. Nada de eso se manifiesta como una tormenta de topología, así que el árbol de fallas del switch no aplica aquí.

A continuación, el camino específico del router: la comprobación de referencia, el descenso a nivel de proceso e hilo para la CPU con los comandos exactos, la nueva captura de flame graph de V600R024C10 para cuando el nombre del proceso por sí solo no dice suficiente, y los comandos de statistics y handle-alloc del lado de la memoria ante una fuga sospechada — además de los inconvenientes y respuestas de preguntas frecuentes que vienen con usar esto realmente en el campo.

CPU o memoria: dos análisis diferentes desde el mismo punto de partida

Ambos comienzan con display health. Después, los comandos divergen por completo.

display health es el único comando que le dice cuál de los dos problemas tiene realmente, y en qué slot — todo lo que sigue se ramifica desde esa única lectura.

Las etiquetas del diagrama se mantienen en inglés para mayor claridad técnica.

Observe que el lado de la CPU tiene una tercera etapa que el lado de la memoria no tiene: una herramienta de captura en vivo. Ese es el flame graph, que solo existe desde V600R024C10 en adelante — en cualquier versión anterior, los campos de pila de llamadas de hilo ya presentes en display cpu-usage top son el respaldo.

Recorriendo cada etapa

Cuatro etapas, los comandos exactos para cada una, y el texto de alarma real que realmente verá.

Etapa 0 — Línea base: una tarjeta, una pantalla

display health coloca el uso de CPU, el uso de memoria y el uso de CPU del plano de datos de cada slot en una sola pantalla — siempre el primer comando, sin importar qué lado del problema sospeche.

<HUAWEI> display health
--------------------------------------------------------------------------------
Slot                        CPU Usage  Memory Usage(Used/Total)     DataPlane CPU Usage
--------------------------------------------------------------------------------
0     MPU(Master)           16%        32%   **82MB/**509MB         0%
--------------------------------------------------------------------------------

Etapa 1 — CPU: encontrar el proceso, luego el hilo

display cpu-usage top le da en una sola pasada los procesos principales y sus hilos, además de la pila de llamadas propia del hilo — vale la pena ejecutarlo antes de suponer nada.

Ejecute display cpu-usage top N desde la vista diagnose para ver el uso de CPU de los N procesos principales, y sus hilos más ocupados debajo de cada uno.
Lea la pila de llamadas del hilo que el comando imprime junto a los números — es lo que un ingeniero de soporte tendría que pedirle por separado.
Si ya tiene un ID de proceso de una comprobación anterior, display cpu-usage slot cpu process processId profundiza un nivel más, en los propios hilos de ese proceso.

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display cpu-usage top 3
Info: This operation needs several seconds.
-------------------------------
Slot 0 CPU 0 information:
-------------------------------
Slot CPU use top 3 process:
-------------------------------------------------------------------
 ProcessID OsProcessID OsProcessname                          Usage
-------------------------------------------------------------------
  33176386       15170 fwmd                                      7%
  33177914       16698 pkimng                                    2%
      1000       18045 HSM                                       1%
-------------------------------------------------------------------
Slot CPU use top 3 thread:
---------------------------------------------------------------------------------------------------------
 ProcessID OsProcessID            Thread ID Thread Type                      Bind Cpu               Usage
---------------------------------------------------------------------------------------------------------
  33176422       15206                15361 PsspSchServer                    0-1                      14%
  33176386       15170                17351 fe_linkscan                      0-1                       3%
  33174969       13753                14231 vcmuagentPwr                     0-1                       2%
---------------------------------------------------------------------------------------------------------
Thread callstack information:
-------------------------------
Thread 0 [tid 15361] (Thread PsspSchServer):
#00  0x0000ffffa73e8f90 from [libc.so.6+0xe3f90](ioctl+0x10)
#01  0x0000ffff7d2d3c84 from [libpssp_sysdiag_daemon.so+0x46c84](GetCallStackInfoByTid+0x4c)
...

Etapa 2 — ¿Esto está en curso, o ya se resolvió?

La alarma de CPU predeterminada muestrea en una ventana de 8 minutos — para cuando usted mira, el pico que la disparó puede haber terminado ya. El historial y los registros le dicen cuál es el caso.

display alarm active (o display alarm history verbose) muestra el texto en bruto de hwCPUUtilizationRisingAlarm, con los valores exactos de CpuUsage y CpuUsageThreshold en el campo de descripción.
display cpu-usage peak history all, ejecutado desde la vista diagnose, muestra el pico diario de uso de CPU del sistema y del plano de datos de los últimos 15 días — útil para confirmar si esto es algo aislado o un patrón recurrente.
Busque en el buffer de registros las entradas SYSDIAG/6/PSSP_CPU_MODULE y DEBUG/4/DEBUG_CPUOVERLOAD — esta última imprime los 3 procesos principales por nombre en el momento exacto de la sobrecarga, con la pila de llamadas de cada hilo debajo.

<HUAWEI> display alarm active
--------------------------------------------------------------------------------
Sequence   AlarmId    Severity Date Time  Description
--------------------------------------------------------------------------------
730        0xF10357   Critical 2025-03-26 The CPU usage exceeded the pre-set overload threshold. (TrapSeverity=3,Proba
                                02:48:52  bleCause=74299,EventType=3,PhysicalIndex=16777217,PhysicalName=MPU slot 0,Re
                                          lativeResource=CPU,UsageType=1,SubIndex=1,CpuUsage=95,Unit=1,CpuUsageThreshol
                                          d=90)
--------------------------------------------------------------------------------

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display cpu-usage peak history all
Slot 0 CPU 0 peak cpu-usage last 15 days:
-------------------------------------------------------------------------------------------------
Index     System cpu-usage(%) SystemPeakDate          Dataplane cpu-usage(%) DataplanePeakDate
-------------------------------------------------------------------------------------------------
0                           5 2025-03-26 00:00:09                          0 2025-03-26 00:00:09
1                           5 2025-03-25 00:00:09                          0 2025-03-25 00:00:09
-------------------------------------------------------------------------------------------------

Etapa 3 — Cuando el nombre del proceso por sí solo no lo explica: el flame graph

V600R024C10 añadió una captura de rendimiento de CPU en vivo que produce un verdadero archivo de flame graph — una herramienta genuinamente nueva, no solo otro comando display.

Inicie la captura con debug system cpu performance, especificando el slot, la CPU, la frecuencia de muestreo y la duración — advierte explícitamente que puede aumentar el uso de CPU y memoria mientras se ejecuta.
Recopile el resultado con el subcomando collect correspondiente una vez transcurrida la ventana de captura.
El archivo de flame graph aterriza en el directorio logfile de la flash como perf_${chassis-id}_${slot-id}_${cpu-id}.unfold — entréguelo a un ingeniero de soporte para leerlo; no está pensado para ser autoexplicativo solo por el nombre del archivo.
La misma captura también puede activarse automáticamente: en cuanto la CPU del plano de control se sobrecarga, o la CPU del plano de datos alcanza (umbral de sobrecarga − 10) %, el equipo genera el flame graph por sí solo, sin necesidad de un comando manual.

<HUAWEI> system-view
[HUAWEI] diagnose
[~HUAWEI-diagnose]debug system cpu performance slot 0 cpu 0 frequency 100 time 20 core 1 process 1
Warning: This operation may cause high CPU and memory usage. Continue? [Y/N]:Y
Info: Operation succeeded.
[~HUAWEI-diagnose]debug system cpu performance slot 0 cpu 0 collect
Warning: This operation may cause high CPU and memory usage. Continue? [Y/N]:Y
Info: Operating, please wait for a moment............
Info: Operation succeeded.
// file: perf_${chassis-id}_${slot-id}_${cpu-id}.unfold, saved under flash logfile
// send this file to a support engineer for interpretation

Etapa 4 — Memoria: de la tabla de procesos al handle que realmente está creciendo

Un número alto de memoria a nivel de proceso por sí solo no prueba una fuga — el desglose a nivel de handle es lo que realmente lo confirma.

display system memory statistics, ejecutado desde la vista diagnose, descompone la memoria total del sistema en memoria de proceso, de sistema de archivos y compartida, y luego lista el VmRSS propio de cada proceso y los campos relacionados.
Una vez que un proceso específico parece sospechoso, display system memory handle-alloc para ese ID de proceso lista cada handle de memoria interno que posee y cuánta memoria está usando cada uno.
Observe el mismo handle a lo largo de comprobaciones repetidas — un handle cuya UsedMemory solo crece, y nunca vuelve a bajar después de que pasa la carga que la elevó, es la verdadera firma de una fuga; recopile la información de alarma, registro y configuración, y escale.

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display system memory statistics slot 1 cpu 0
Slot 1 Cpu 0 memory utilization statistics at 2010-11-30 13:02:29 379 ms
------------------------------------------------------------------------------------------------------------------------------------
System Total                                                                                                 : 15592564 kB
System Used                                                                                                  : 5640984 kB
System Free                                                                                                  : 9951580 kB
------------------------------------------------------------------------------------------------------------------------------------
ProcessID      OsProcID       ProcName        VmSize    VmAs(Virtual Memory)      VmRSS      VmData    VmStk     VmExe     VmLib     Shmem     HugePage
-------------------------------------------------------------------------------------------------------------------------------------------------------
6              17275          CM              25000080  208124                    287192     207996    128       292       101504    2952720   1640448
33176386       15170          fwmd            164773728 299648                    265828     299520    128       744       117752    137730664 1640448

<HUAWEI> system-view
[HUAWEI] diagnose
[HUAWEI-diagnose] display system memory handle-alloc slot 0 cpu 0 process 883
----------------------------------------------------------------------------
HandleID HandleName                                          UsedMemory(B)
----------------------------------------------------------------------------
16 vos_queue                                               1,100,360
17 vos.simplemem.page.handle                               2,299,360
18 vos.simplemem.handle                                      216,016
19 v_vfs                                                     230,480
// re-check the same HandleID over time -- a value that only ever grows is the leak signature

6 inconvenientes en el propio análisis de CPU/memoria

Los comandos de diagnóstico tienen sus propios bordes afilados — estos son los que sorprenden a los ingenieros.

1. La alarma predeterminada solo se dispara tras 8 minutos de sobrecarga sostenida

SÍNTOMAUn usuario se queja de que el router "estuvo lento por un minuto", pero no aparece ninguna alarma de CPU en display alarm active ni en la lista de alarmas actuales.

CAUSAhwCPUUtilizationRisingAlarm muestrea el uso de CPU en un ciclo fijo — 8 minutos por defecto — y solo dispara la alarma si cada muestra de esa ventana permanece por encima del umbral de sobrecarga (90% por defecto). Un pico que se resuelve dentro de la ventana nunca cruza esa barrera, aunque haya sido real.

SOLUCIÓNNo confíe solo en la lista de alarmas para un pico breve — verifique con display cpu-usage peak history all el pico diario, y el buffer de registros en busca de entradas DEBUG/4/DEBUG_CPUOVERLOAD, que registran el momento y los 3 procesos principales incluso sin alarma formal.

StartTime   : 2025-03-26 02:48:52 ... CpuUsage=95 ... CpuUsageThreshold=90
ClearTime   : 2025-03-26 02:50:19 ... CpuUsage=5 ... CpuUsageThreshold=87
// alarm active for under 2 minutes here -- a shorter spike might not clear the 8-minute sampling window at all

2. Ejecutar los propios comandos de diagnóstico puede empeorar un equipo ya cargado

SÍNTOMAEl uso de CPU sube aún más justo después de ejecutar display cpu-usage top o display diagnostic-information en un equipo que ya tiene dificultades.

CAUSAAmbos comandos están explícitamente documentados como operaciones que pueden aumentar el uso de CPU mientras se ejecutan, y ejecutarlos de forma redundante desde varias sesiones de terminal a la vez agrava el efecto en un equipo ya cargado.

SOLUCIÓNRecurra a display cpu-usage top — el comando más ligero y específico — antes que al paquete mucho más pesado display diagnostic-information, y nunca ejecute ninguno de los dos desde más de una sesión en el mismo equipo al mismo tiempo.

3. El flame graph es una nueva función de V600R024C10 — y el archivo aún necesita que un humano lo lea

SÍNTOMAExiste un archivo perf_*.unfold en el directorio logfile, pero nadie in situ puede decir qué significa realmente.

CAUSALa captura debug system cpu performance solo está disponible desde V600R024C10 en adelante, y la propia herramienta advierte que ejecutarla puede aumentar el uso de CPU y memoria — está pensada para una investigación activa, no para comprobaciones de rutina. El flame graph resultante es un artefacto de muestreo en bruto, no un informe etiquetado; leerlo correctamente requiere a alguien capacitado en el formato.

SOLUCIÓNEn V600R024C10 y versiones posteriores, capture el flame graph solo cuando ya sospeche que la CPU es el problema, y envíe el archivo .unfold a un ingeniero de soporte en lugar de intentar interpretarlo en frío. En versiones anteriores, recurra a los campos de pila de llamadas de hilo ya impresos por display cpu-usage top.

4. DEBUG_CPUOVERLOAD solo imprime los 3 procesos principales

SÍNTOMAEl registro muestra tres procesos en el momento de la sobrecarga, pero el que realmente sospecha no está en la lista.

CAUSALa entrada de registro DEBUG/4/DEBUG_CPUOVERLOAD está documentada como que imprime solo los tres procesos principales por ocupación de CPU en el momento de la sobrecarga — un culpable en cuarto lugar simplemente no entra en la lista.

SOLUCIÓNEjecute directamente display cpu-usage top con un show-num más alto, en lugar de confiar en la vista fija de los 3 principales del registro, siempre que los tres nombres del registro no coincidan con lo esperado.

5. Un número alto de memoria de proceso no prueba por sí solo una fuga

SÍNTOMAEl VmRSS de un proceso en display system memory statistics parece grande, y es tentador señalarlo de inmediato como la fuga.

CAUSAUn proceso puede tener legítimamente una gran cantidad de memoria para su conjunto de trabajo normal. La verdadera firma de la fuga solo aparece un nivel más abajo, en display system memory handle-alloc — un handle específico dentro de ese proceso cuya UsedMemory sigue subiendo y nunca vuelve a la línea base una vez que pasa la carga que la elevó.

SOLUCIÓNAntes de escalar una "fuga de memoria", vuelva a comprobar la salida de handle-alloc del mismo proceso en más de una muestra y confirme que al menos un handle crece de forma monótona — no solo que el total del proceso parecía grande una vez.

6. En un chasis con doble control principal, cada tarjeta mantiene su propio estado de CPU/memoria

SÍNTOMAdisplay health y display cpu-usage en la tarjeta activa se ven completamente normales, pero el síntoma reportado (una conmutación, una ralentización) no coincide.

CAUSACada comando de esta nota ejecutado en la tarjeta de control principal activa solo informa la CPU y memoria de esa propia tarjeta — la tarjeta en espera mantiene un estado completamente separado y hay que acceder a ella por separado para confirmar si era la que estaba bajo carga. Esta es la misma advertencia tratada con más detalle en Fault Information to Collect Before You Escalate.

SOLUCIÓNDesde la vista diagnose, use local-telnet slave para acceder a la tarjeta en espera y vuelva a ejecutar display health / display cpu-usage top allí también, antes de concluir que las lecturas de la tarjeta activa son todo el panorama.

<HUAWEI> diagnose
[HUAWEI-diagnose] local-telnet slave
<HUAWEI> display health

Seis preguntas que surgen constantemente

Extraídas directamente del campo — las que vale la pena tener respondidas de antemano.

¿Cuál es el umbral de alarma de CPU predeterminado, y cuánto tarda en dispararse realmente?

El umbral de sobrecarga predeterminado es 90% de uso de CPU, muestreado en un ciclo de 8 minutos por hwCPUUtilizationRisingAlarm — la alarma solo se dispara si cada muestra de esa ventana permanece por encima del 90%. El umbral de borrado está un poco por debajo (87% en un caso real típico), por lo que un pico puede aparecer y desaparecer más rápido que el propio mecanismo de alarma.

¿Cuál es la diferencia real entre display cpu-usage y display cpu-usage top?

display cpu-usage (y display health) le dan el porcentaje a nivel de tarjeta — útil para confirmar que hay un problema. display cpu-usage top, ejecutado desde la vista diagnose, descompone ese número en los procesos e hilos realmente responsables, más la pila de llamadas propia de cada hilo — es el comando que responde "cuál".

Ya tengo un nombre de proceso de cpu-usage top — ¿sigo necesitando el flame graph?

No siempre. Recurra al flame graph específicamente cuando el nombre del proceso por sí solo no explica la carga — un proceso legítimamente ocupado por una razón que usted comprende no lo necesita. Se justifica en los casos donde la vista de proceso/hilo sigue apuntando a algo que no tiene sentido por sí solo.

¿Un número alto en la tabla de procesos de display system memory statistics es el problema en sí?

No por sí solo — vea el inconveniente anterior. Un VmRSS grande puede ser el conjunto de trabajo normal de un proceso. La verdadera firma de la fuga está un nivel más abajo, en display system memory handle-alloc para ese proceso: un handle específico cuya UsedMemory sigue subiendo en comprobaciones repetidas y nunca vuelve a bajar.

Mi equipo es un switch, no un router — ¿es el mismo árbol de fallas?

No. Los tickets de CPU alta de un switch son mucho más a menudo una tormenta TC o un bucle MSTP recalculando la topología que un solo proceso descontrolado — vea Switch CPU Utilization High: Finding What's Eating the Control Plane para ese camino específico en lugar de este.

¿Qué versiones de software del router realmente admiten el flame graph?

La captura debug system cpu performance y el archivo de flame graph resultante son nuevos desde V600R024C10 en adelante. En cualquier versión anterior, no hay flame graph de respaldo — los campos de pila de llamadas de hilo impresos directamente dentro de display cpu-usage top son la herramienta equivalente para esas versiones.

Límites honestos de esta nota

Límites honestos de esta nota

Esta nota se construye en torno al modelo de resolución de problemas de CPU/memoria V600 del router de la serie AR de Huawei y sus comandos display health / cpu-usage / memory statistics / handle-alloc, más la captura de flame graph de V600R024C10, tomados del propio manual de mantenimiento AR de Huawei. No cubre una lista específica de causas raíz de fugas de memoria — un handle en crecimiento siempre necesita que un ingeniero de soporte lea el flame graph o la salida de handle-alloc y confirme qué está reteniendo realmente la memoria. En software anterior a V600R024C10, considere los pasos del flame graph como no aplicables y confíe en la vista de pila de llamadas de hilo.

¿Está leyendo un volcado de CPU o memoria y está atascado?

Envíenos su salida de display health / cpu-usage top, o el archivo .unfold del flame graph, y le ayudamos a interpretarlo.

WhatsApp con un ingeniero →