Início / Notas técnicas / Solução de problemas de CPU e memória do roteador

CPU e memória do roteador muito altos: de display health aos flame graphs

Um roteador AR com a CPU no limite, ou com um vazamento lento de memória, não quebra como um switch enfrentando uma tempestade TC ou um loop MSTP — geralmente é um único processo, uma única thread, ou um handle de memória que só cresce. Esta é a escada de comandos que encontra isso: display health como linha de base, display cpu-usage top para o processo culpado e — novidade desde a V600R024C10 — um flame graph real para o caso em que o nome do processo sozinho não explica a carga.

Por Yuwen Zhang (Atlas), fundador da AtlasCommTech — 13 anos de implantações de redes de operadoras e empresariais · Atualizado em julho de 2026

Por que este não é o manual do switch

O plano de controle de um roteador satura por razões diferentes das de um switch — perseguir o culpado errado desperdiça a tarde toda.

Se o equipamento à sua frente é um switch e a CPU está saturada, isso costuma ser uma tempestade TC ou um loop MSTP recalculando a topologia — veja Switch CPU Utilization High: Finding What's Eating the Control Plane para esse caminho. As queixas de CPU e memória de um roteador AR costumam ter outra forma: um processo esquentando silenciosamente, uma thread presa em loop, ou um handle de memória interno a um processo que só cresce e nunca devolve. Nada disso aparece como uma tempestade de topologia, então a árvore de falhas do switch não se aplica aqui.

A seguir está o caminho específico do roteador: a verificação de linha de base, o detalhamento a nível de processo e thread para a CPU com os comandos exatos, a nova captura de flame graph da V600R024C10 para quando o nome do processo sozinho não explica o suficiente, e os comandos de statistics e handle-alloc do lado da memória diante de um vazamento suspeito — além das pegadinhas e respostas de FAQ que vêm com usar isso de fato em campo.

CPU ou memória — dois aprofundamentos diferentes a partir do mesmo ponto de partida

Ambos começam com display health. Depois disso, os comandos divergem completamente.

display health é o único comando que diz qual dos dois problemas você realmente tem, e em qual slot — tudo abaixo se ramifica a partir dessa única leitura.

Os rótulos do diagrama são mantidos em inglês para clareza técnica.

Observe que o lado da CPU tem uma terceira etapa que o lado da memória não tem: uma ferramenta de captura ao vivo. Esse é o flame graph, que só existe a partir da V600R024C10 — em qualquer versão anterior, os campos de call stack de thread já presentes no display cpu-usage top servem de alternativa.

Percorrendo cada etapa

Quatro etapas, os comandos exatos para cada uma, e o texto real do alarme que você realmente verá.

Etapa 0 — Linha de base: uma placa, uma tela

display health coloca o uso de CPU, o uso de memória e o uso de CPU do plano de dados de cada slot em uma única tela — sempre o primeiro comando, seja qual for o lado do problema que você suspeita.

<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 o processo, depois a thread

display cpu-usage top fornece em uma única passagem os principais processos e suas threads, além do call stack próprio da thread — vale a pena executá-lo antes de supor qualquer coisa.

Execute display cpu-usage top N a partir da view diagnose para ver o uso de CPU dos N principais processos, e suas threads mais ocupadas abaixo de cada um.
Leia o call stack da thread que o comando imprime junto com os números — é o que um engenheiro de suporte teria que pedir separadamente.
Se você já tem um ID de processo de uma verificação anterior, display cpu-usage slot cpu process processId aprofunda mais um nível, nas próprias threads daquele processo.

<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 — Isso está ao vivo, ou já foi resolvido?

O alarme padrão de CPU faz amostragem em uma janela de 8 minutos — quando você for olhar, o pico que o disparou já pode ter acabado. O histórico e os logs dizem qual é o caso.

display alarm active (ou display alarm history verbose) mostra o texto bruto do hwCPUUtilizationRisingAlarm, com os valores exatos de CpuUsage e CpuUsageThreshold no campo de descrição.
display cpu-usage peak history all, executado a partir da view diagnose, mostra o pico diário de uso de CPU do sistema e do plano de dados dos últimos 15 dias — útil para confirmar se isso é algo isolado ou um padrão recorrente.
Procure no buffer de logs as entradas SYSDIAG/6/PSSP_CPU_MODULE e DEBUG/4/DEBUG_CPUOVERLOAD — esta última imprime os 3 principais processos por nome no momento exato da sobrecarga, com o call stack de cada thread abaixo.

<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 — Quando o nome do processo sozinho não explica: o flame graph

A V600R024C10 adicionou uma captura de desempenho de CPU ao vivo que gera um arquivo de flame graph real — uma ferramenta genuinamente nova, não apenas mais um comando display.

Inicie a captura com debug system cpu performance, especificando o slot, a CPU, a frequência de amostragem e a duração — ele avisa explicitamente que pode aumentar o uso de CPU e memória durante a execução.
Colete o resultado com o subcomando collect correspondente após o término da janela de captura.
O arquivo de flame graph vai para o diretório logfile da flash como perf_${chassis-id}_${slot-id}_${cpu-id}.unfold — entregue-o a um engenheiro de suporte para leitura; ele não deve ser autoexplicativo apenas pelo nome do arquivo.
A mesma captura também pode se disparar automaticamente: assim que a CPU do plano de controle sobrecarrega, ou a CPU do plano de dados atinge (limite de sobrecarga − 10)%, o dispositivo gera o flame graph sozinho, sem 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 — Memória: da tabela de processos ao handle que realmente está crescendo

Um número alto de memória em nível de processo por si só não prova um vazamento — o detalhamento em nível de handle é o que realmente informa.

display system memory statistics, executado a partir da view diagnose, decompõe a memória total do sistema em memória de processo, de sistema de arquivos e compartilhada, e depois lista o VmRSS próprio de cada processo e os campos relacionados.
Uma vez que um processo específico pareça suspeito, display system memory handle-alloc para aquele ID de processo lista cada handle de memória interno que ele mantém e quanta memória cada um está usando.
Observe o mesmo handle em verificações repetidas — um handle cuja UsedMemory só cresce, e nunca volta a cair depois que a carga que a elevou passa, é a verdadeira assinatura de vazamento; colete as informações de alarme, log e configuração, e 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 pegadinhas no próprio detalhamento de CPU/memória

Os comandos de diagnóstico têm suas próprias arestas — estas são as que pegam os engenheiros de surpresa.

1. O alarme padrão só dispara após 8 minutos de sobrecarga sustentada

SINTOMAUm usuário reclama que o roteador "ficou lento por um minuto", mas nenhum alarme de CPU aparece em display alarm active nem na lista de alarmes atuais.

CAUSAO hwCPUUtilizationRisingAlarm faz amostragem do uso de CPU em um ciclo fixo — 8 minutos por padrão — e só dispara o alarme se cada amostra dessa janela permanecer acima do limite de sobrecarga (90% por padrão). Um pico que se resolve dentro da janela nunca ultrapassa essa barreira, mesmo tendo sido real.

SOLUÇÃONão confie apenas na lista de alarmes para um pico de curta duração — cruze com display cpu-usage peak history all para o pico diário, e o buffer de logs em busca de entradas DEBUG/4/DEBUG_CPUOVERLOAD, que registram o momento e os 3 principais processos mesmo sem alarme 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. Executar os próprios comandos de diagnóstico pode piorar um equipamento já sobrecarregado

SINTOMAO uso de CPU sobe ainda mais logo após a execução de display cpu-usage top ou display diagnostic-information em um equipamento que já está com dificuldades.

CAUSAAmbos os comandos são explicitamente documentados como operações que podem aumentar o uso de CPU durante a execução, e executá-los de forma redundante em várias sessões de terminal ao mesmo tempo agrava o efeito em um dispositivo já sobrecarregado.

SOLUÇÃORecorra ao display cpu-usage top — o comando mais leve e direcionado — antes do pacote muito mais pesado display diagnostic-information, e nunca execute nenhum dos dois em mais de uma sessão no mesmo dispositivo ao mesmo tempo.

3. O flame graph é um novo recurso da V600R024C10 — e o arquivo ainda precisa de um humano para lê-lo

SINTOMAExiste um arquivo perf_*.unfold no diretório logfile, mas ninguém no local consegue dizer o que ele realmente significa.

CAUSAA captura debug system cpu performance só está disponível a partir da V600R024C10, e a própria ferramenta avisa que executá-la pode aumentar o uso de CPU e memória — ela é destinada a investigações ativas, não a verificações de rotina. O flame graph resultante é um artefato de amostragem bruto, não um relatório rotulado; lê-lo corretamente exige alguém treinado nesse formato.

SOLUÇÃONa V600R024C10 e versões posteriores, capture o flame graph somente quando você já suspeitar que a CPU é o problema, e envie o arquivo .unfold a um engenheiro de suporte em vez de tentar interpretá-lo por conta própria. Em versões anteriores, recorra aos campos de call stack de thread já impressos pelo display cpu-usage top.

4. O DEBUG_CPUOVERLOAD só imprime os 3 principais processos

SINTOMAO log mostra três processos no momento da sobrecarga, mas aquele que você realmente suspeita não está na lista.

CAUSAA entrada de log DEBUG/4/DEBUG_CPUOVERLOAD está documentada como imprimindo apenas os três principais processos por ocupação de CPU no momento da sobrecarga — um culpado em quarto lugar simplesmente não entra na lista.

SOLUÇÃOExecute diretamente display cpu-usage top com um show-num mais alto, em vez de confiar na visão fixa dos 3 principais do log, sempre que os três nomes do log não corresponderem ao esperado.

5. Um número alto de memória de processo não prova por si só um vazamento

SINTOMAO VmRSS de um processo em display system memory statistics parece grande, e é tentador apontá-lo de imediato como o vazamento.

CAUSAUm processo pode legitimamente manter uma grande quantidade de memória para seu conjunto de trabalho normal. A verdadeira assinatura do vazamento só aparece um nível abaixo, em display system memory handle-alloc — um handle específico dentro daquele processo cuja UsedMemory continua subindo e nunca volta à linha de base depois que a carga que a elevou passa.

SOLUÇÃOAntes de escalar um "vazamento de memória", reverifique a saída de handle-alloc do mesmo processo em mais de uma amostra e confirme que pelo menos um handle está crescendo monotonicamente — não apenas que o total do processo parecia grande uma vez.

6. Em um chassi com controle principal duplo, cada placa mantém seu próprio estado de CPU/memória

SINTOMAdisplay health e display cpu-usage na placa ativa parecem completamente normais, mas o sintoma relatado (um failover, uma lentidão) não bate.

CAUSACada comando desta nota executado na placa de controle principal ativa só informa a CPU e a memória daquela própria placa — a placa em espera mantém um estado totalmente separado e precisa ser acessada isoladamente para confirmar se era ela que estava sob carga. Esta é a mesma ressalva tratada com mais detalhes em Fault Information to Collect Before You Escalate.

SOLUÇÃOA partir da view diagnose, use local-telnet slave para acessar a placa em espera e execute novamente display health / display cpu-usage top lá também, antes de concluir que as leituras da placa ativa são todo o quadro.

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

Seis perguntas que surgem constantemente

Tiradas diretamente do campo — aquelas para as quais vale a pena ter uma resposta pronta.

Qual é o limite padrão do alarme de CPU, e quanto tempo leva para ele realmente disparar?

O limite de sobrecarga padrão é 90% de uso de CPU, amostrado em um ciclo de 8 minutos pelo hwCPUUtilizationRisingAlarm — o alarme só dispara se cada amostra dessa janela permanecer acima de 90%. O limite de limpeza fica um pouco abaixo (87% em um caso real típico), então um pico pode ir e voltar mais rápido que o próprio mecanismo de alarme.

Qual é a real diferença entre display cpu-usage e display cpu-usage top?

display cpu-usage (e display health) fornecem a porcentagem em nível de placa — útil para confirmar que há um problema. display cpu-usage top, executado a partir da view diagnose, decompõe esse número nos processos e threads realmente responsáveis, mais o call stack próprio de cada thread — é o comando que responde "qual".

Já tenho um nome de processo do cpu-usage top — ainda preciso do flame graph?

Nem sempre. Recorra ao flame graph especificamente quando o nome do processo sozinho não explica a carga — um processo legitimamente ocupado por um motivo que você entende não precisa dele. Ele se justifica nos casos em que a visão de processo/thread continua apontando para algo que não faz sentido por si só.

Um número alto na tabela de processos do display system memory statistics já é o problema?

Não por si só — veja a pegadinha acima. Um VmRSS grande pode ser o conjunto de trabalho normal de um processo. A verdadeira assinatura do vazamento está um nível abaixo, em display system memory handle-alloc para aquele processo: um handle específico cuja UsedMemory continua subindo em verificações repetidas e nunca volta a cair.

Meu dispositivo é um switch, não um roteador — é a mesma árvore de falhas?

Não. Os chamados de CPU alta de um switch são muito mais frequentemente uma tempestade TC ou um loop MSTP recalculando a topologia do que um único processo descontrolado — veja Switch CPU Utilization High: Finding What's Eating the Control Plane para esse caminho específico em vez deste.

Quais versões de software do roteador realmente suportam o flame graph?

A captura debug system cpu performance e o arquivo de flame graph resultante são novos a partir da V600R024C10. Em qualquer versão anterior, não há flame graph como alternativa — os campos de call stack de thread impressos diretamente dentro do display cpu-usage top são a ferramenta equivalente para essas versões.

Limites honestos desta nota

Limites honestos desta nota

Esta nota é construída em torno do modelo de solução de problemas de CPU/memória V600 do roteador Huawei série AR e seus comandos display health / cpu-usage / memory statistics / handle-alloc, além da captura de flame graph da V600R024C10, extraídos do próprio manual de manutenção AR da Huawei. Ela não cobre uma lista específica de causas-raiz de vazamento de memória — um handle em crescimento sempre ainda precisa que um engenheiro de suporte leia o flame graph ou a saída do handle-alloc e confirme o que realmente está retendo a memória. Em software anterior à V600R024C10, trate as etapas do flame graph como não aplicáveis e confie na visão de call stack de thread.

Está lendo um dump de CPU ou memória e está travado?

Envie-nos sua saída de display health / cpu-usage top, ou o arquivo .unfold do flame graph, e ajudamos a interpretar.

WhatsApp com um engenheiro →