Accueil / Notes techniques / Dépannage CPU et mémoire du routeur

CPU et mémoire du routeur trop élevés : de display health aux flame graphs

Un routeur AR à CPU élevé, ou qui fuit lentement de la mémoire, ne tombe pas en panne comme un commutateur aux prises avec une tempête TC ou une boucle MSTP — c'est généralement un seul processus, un seul thread, ou un handle mémoire qui ne cesse de grossir. Voici l'échelle de commandes qui permet de le trouver : display health pour la référence, display cpu-usage top pour le processus fautif, et — nouveau depuis V600R024C10 — un véritable flame graph pour le cas où le nom du processus seul ne suffit pas à expliquer la charge.

Par Yuwen Zhang (Atlas), fondateur d'AtlasCommTech — 13 ans de déploiements de réseaux opérateurs et d'entreprise · Mis à jour en juillet 2026

Pourquoi ce n'est pas le même guide que pour un commutateur

Le plan de contrôle d'un routeur sature pour des raisons différentes de celui d'un commutateur — poursuivre le mauvais coupable fait perdre tout un après-midi.

Si l'appareil devant vous est un commutateur et que le CPU sature, il s'agit très souvent d'une tempête TC ou d'une boucle MSTP recalculant la topologie — voir Switch CPU Utilization High: Finding What's Eating the Control Plane pour ce chemin-là. Les plaintes de CPU et mémoire d'un routeur AR ont généralement une autre forme : un processus qui chauffe discrètement, un thread bloqué dans une boucle, ou un handle mémoire interne à un processus qui ne cesse de grossir sans jamais redescendre. Rien de tout cela ne se manifeste comme une tempête de topologie, donc l'arbre de panne du commutateur ne s'applique pas ici.

Voici le chemin propre au routeur : la vérification de référence, la descente au niveau processus et thread pour le CPU avec les commandes exactes, la nouvelle capture de flame graph V600R024C10 pour le cas où le nom du processus seul n'en dit pas assez, et les commandes statistics et handle-alloc côté mémoire en cas de fuite suspectée — plus les pièges et réponses de FAQ qui viennent avec l'usage réel sur le terrain.

CPU ou mémoire — deux approfondissements différents à partir du même point de départ

Les deux commencent par display health. Ensuite, les commandes divergent complètement.

display health est la seule commande qui vous indique lequel des deux problèmes vous avez réellement, et sur quel slot — tout ce qui suit découle de cette seule lecture.

Les libellés du diagramme sont conservés en anglais pour la clarté technique.

Remarquez que le côté CPU a une troisième étape que le côté mémoire n'a pas : un outil de capture en direct. C'est le flame graph, qui n'existe qu'à partir de V600R024C10 — sur toute version antérieure, les champs de pile d'appels de thread déjà présents dans display cpu-usage top servent de solution de repli.

Parcourir chaque étape

Quatre étapes, les commandes exactes pour chacune, et le texte d'alarme réel que vous verrez effectivement.

Étape 0 — Référence : une carte, un écran

display health regroupe l'utilisation CPU, l'utilisation mémoire et l'utilisation CPU du plan de données pour chaque slot sur un seul écran — toujours la première commande, quel que soit le côté du problème que vous suspectez.

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

Étape 1 — CPU : trouver le processus, puis le thread

display cpu-usage top donne en une seule passe les principaux processus et leurs threads, plus la pile d'appels propre au thread — à exécuter avant toute supposition.

Exécutez display cpu-usage top N depuis la vue diagnose pour voir l'utilisation CPU des N principaux processus, et leurs threads les plus occupés en dessous.
Lisez la pile d'appels du thread que la commande imprime à côté des chiffres — c'est ce qu'un ingénieur support devrait sinon vous demander séparément.
Si vous avez déjà un ID de processus issu d'une vérification précédente, display cpu-usage slot cpu process processId descend d'un niveau supplémentaire, dans les threads propres à ce processus.

<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)
...

Étape 2 — Est-ce en cours, ou déjà résolu ?

L'alarme CPU par défaut échantillonne sur une fenêtre de 8 minutes — le temps que vous regardiez, le pic qui l'a déclenchée peut déjà être terminé. L'historique et les journaux vous disent lequel.

display alarm active (ou display alarm history verbose) affiche le texte brut de hwCPUUtilizationRisingAlarm, avec les valeurs exactes de CpuUsage et CpuUsageThreshold dans le champ de description.
display cpu-usage peak history all, exécuté depuis la vue diagnose, montre le pic quotidien d'utilisation CPU système et plan de données des 15 derniers jours — utile pour confirmer s'il s'agit d'un incident isolé ou d'un motif récurrent.
Recherchez dans le tampon de journaux les entrées SYSDIAG/6/PSSP_CPU_MODULE et DEBUG/4/DEBUG_CPUOVERLOAD — cette dernière imprime les 3 principaux processus par nom au moment exact de la surcharge, avec la pile d'appels de chaque thread en dessous.

<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
-------------------------------------------------------------------------------------------------

Étape 3 — Quand le nom du processus seul ne suffit pas : le flame graph

V600R024C10 a ajouté une capture de performance CPU en direct qui produit un véritable fichier de flame graph — un outil véritablement nouveau, pas juste une commande display de plus.

Démarrez la capture avec debug system cpu performance, en spécifiant le slot, le CPU, la fréquence d'échantillonnage et la durée — elle avertit explicitement qu'elle peut augmenter l'utilisation CPU et mémoire pendant son exécution.
Récupérez le résultat avec la sous-commande collect correspondante une fois la fenêtre de capture écoulée.
Le fichier de flame graph atterrit dans le répertoire logfile de la flash sous le nom perf_${chassis-id}_${slot-id}_${cpu-id}.unfold — remettez-le à un ingénieur support pour le lire ; il n'est pas censé se comprendre de lui-même à partir du seul nom de fichier.
La même capture peut aussi se déclencher automatiquement : dès que le CPU du plan de contrôle sature, ou que le CPU du plan de données atteint (seuil de surcharge − 10) %, l'appareil génère le flame graph de lui-même, sans commande manuelle.

<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

Étape 4 — Mémoire : de la table des processus au handle qui grossit réellement

Un chiffre élevé de mémoire au niveau processus ne prouve pas à lui seul une fuite — c'est la décomposition au niveau des handles qui le confirme réellement.

display system memory statistics, exécuté depuis la vue diagnose, décompose la mémoire système totale en mémoire de processus, de système de fichiers et partagée, puis liste le VmRSS propre à chaque processus et les champs associés.
Une fois qu'un processus précis paraît suspect, display system memory handle-alloc pour cet ID de processus liste chaque handle mémoire interne qu'il détient et la quantité de mémoire que chacun utilise.
Observez le même handle sur des vérifications répétées — un handle dont la UsedMemory ne fait que croître, et ne redescend jamais après la charge qui l'a fait grimper, est la véritable signature d'une fuite ; collectez les informations d'alarme, de journal et de configuration, puis escaladez.

<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 pièges dans l'approfondissement CPU/mémoire lui-même

Les commandes de diagnostic ont leurs propres aspérités — voici celles qui prennent les ingénieurs au dépourvu.

1. L'alarme par défaut ne se déclenche qu'après 8 minutes de surcharge soutenue

SYMPTÔMEUn utilisateur se plaint que le routeur « a été lent pendant une minute », mais aucune alarme CPU n'apparaît dans display alarm active ni dans la liste des alarmes actuelles.

CAUSEhwCPUUtilizationRisingAlarm échantillonne l'utilisation CPU sur un cycle fixe — 8 minutes par défaut — et ne déclenche l'alarme que si chaque échantillon de cette fenêtre reste au-dessus du seuil de surcharge (90 % par défaut). Un pic qui se résorbe dans la fenêtre ne franchit jamais cette barre, même s'il était bien réel.

SOLUTIONNe vous fiez pas uniquement à la liste des alarmes pour un pic de courte durée — recoupez avec display cpu-usage peak history all pour le pic quotidien, et le tampon de journaux pour les entrées DEBUG/4/DEBUG_CPUOVERLOAD, qui consignent le moment et les 3 principaux processus même sans alarme formelle.

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. Exécuter les commandes de diagnostic elles-mêmes peut aggraver un boîtier déjà chargé

SYMPTÔMEL'utilisation CPU grimpe encore juste après l'exécution de display cpu-usage top ou display diagnostic-information sur un boîtier déjà en difficulté.

CAUSELes deux commandes sont explicitement documentées comme des opérations pouvant augmenter l'utilisation CPU pendant leur exécution, et les exécuter de façon redondante depuis plusieurs sessions de terminal à la fois amplifie l'effet sur un appareil déjà chargé.

SOLUTIONPrivilégiez display cpu-usage top — la commande plus légère et ciblée — avant le bundle bien plus lourd display diagnostic-information, et n'exécutez jamais l'une ou l'autre depuis plusieurs sessions sur le même appareil en même temps.

3. Le flame graph est une nouvelle fonctionnalité de V600R024C10 — et le fichier a toujours besoin d'un humain pour être lu

SYMPTÔMEUn fichier perf_*.unfold existe dans le répertoire logfile, mais personne sur place ne peut dire ce qu'il signifie réellement.

CAUSELa capture debug system cpu performance n'est disponible qu'à partir de V600R024C10, et l'outil lui-même avertit que son exécution peut augmenter l'utilisation CPU et mémoire — elle est destinée à une investigation active, pas à des contrôles de santé de routine. Le flame graph résultant est un artefact d'échantillonnage brut, pas un rapport étiqueté ; le lire correctement demande quelqu'un formé à ce format.

SOLUTIONSur V600R024C10 et versions ultérieures, ne capturez le flame graph qu'une fois que vous suspectez déjà le CPU comme problème, et envoyez le fichier .unfold à un ingénieur support plutôt que d'essayer de l'interpréter à froid. Sur les versions antérieures, repliez-vous sur les champs de pile d'appels de thread déjà imprimés par display cpu-usage top.

4. DEBUG_CPUOVERLOAD n'imprime que les 3 principaux processus

SYMPTÔMELe journal montre trois processus au moment de la surcharge, mais celui que vous suspectez réellement n'est pas du tout dans la liste.

CAUSEL'entrée de journal DEBUG/4/DEBUG_CPUOVERLOAD est documentée comme n'imprimant que les trois principaux processus par occupation CPU au moment de la surcharge — un coupable classé quatrième n'entre tout simplement pas dans la liste.

SOLUTIONExécutez directement display cpu-usage top avec un show-num plus élevé, plutôt que de vous fier à la vue fixe des 3 principaux du journal, chaque fois que les trois noms du journal ne correspondent pas à ce que vous attendez.

5. Un chiffre élevé de mémoire processus ne prouve pas à lui seul une fuite

SYMPTÔMELe VmRSS d'un processus dans display system memory statistics paraît important, et il est tentant de le désigner immédiatement comme la fuite.

CAUSEUn processus peut légitimement détenir une grande quantité de mémoire pour son ensemble de travail normal. La signature réelle de fuite n'apparaît qu'un niveau plus bas, dans display system memory handle-alloc — un handle spécifique à l'intérieur de ce processus dont la UsedMemory ne cesse de croître et ne revient jamais à la référence une fois la charge qui l'a fait grimper passée.

SOLUTIONAvant d'escalader une « fuite mémoire », revérifiez la sortie handle-alloc du même processus sur plus d'un échantillon et confirmez qu'au moins un handle croît de manière monotone — pas seulement que le total du processus paraissait important une fois.

6. Sur un châssis à double contrôle principal, chaque carte conserve son propre état CPU/mémoire

SYMPTÔMEdisplay health et display cpu-usage sur la carte active paraissent tout à fait normaux, mais le symptôme signalé (un basculement, un ralentissement) ne correspond pas.

CAUSEChaque commande de cette note exécutée sur la carte de contrôle principale active ne rapporte que le CPU et la mémoire de cette carte elle-même — la carte de secours conserve un état entièrement séparé et doit être atteinte séparément pour confirmer si c'est elle qui était sous charge. C'est la même mise en garde détaillée dans Fault Information to Collect Before You Escalate.

SOLUTIONDepuis la vue diagnose, utilisez local-telnet slave pour atteindre la carte de secours et réexécutez display health / display cpu-usage top là aussi, avant de conclure que les relevés de la carte active donnent toute l'image.

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

Six questions qui reviennent sans cesse

Tirées directement du terrain — celles pour lesquelles il vaut la peine d'avoir une réponse prête.

Quel est le seuil d'alarme CPU par défaut, et au bout de combien de temps se déclenche-t-elle réellement ?

Le seuil de surcharge par défaut est de 90 % d'utilisation CPU, échantillonné sur un cycle de 8 minutes par hwCPUUtilizationRisingAlarm — l'alarme ne se déclenche que si chaque échantillon de cette fenêtre reste au-dessus de 90 %. Le seuil de suppression est légèrement inférieur (87 % dans un cas réel typique), donc un pic peut aller et venir plus vite que le mécanisme d'alarme lui-même.

Quelle est la différence réelle entre display cpu-usage et display cpu-usage top ?

display cpu-usage (et display health) vous donne le pourcentage au niveau de la carte — utile pour confirmer qu'il y a bien un problème. display cpu-usage top, exécuté depuis la vue diagnose, décompose ce chiffre en les processus et threads réellement responsables, plus la pile d'appels propre à chaque thread — c'est la commande qui répond à « lequel ».

J'ai déjà un nom de processus depuis cpu-usage top — ai-je encore besoin du flame graph ?

Pas toujours. Recourez au flame graph spécifiquement quand le nom du processus seul n'explique pas la charge — un processus légitimement occupé pour une raison que vous comprenez n'en a pas besoin. Il justifie son coût dans les cas où la vue processus/thread continue de pointer vers quelque chose qui ne fait pas sens à lui seul.

Un chiffre élevé dans la table des processus de display system memory statistics est-il le problème en soi ?

Pas à lui seul — voir le piège ci-dessus. Un VmRSS important peut être l'ensemble de travail normal d'un processus. La véritable signature de fuite se trouve un niveau plus bas, dans display system memory handle-alloc pour ce processus : un handle spécifique dont la UsedMemory ne cesse de croître au fil des vérifications répétées et ne redescend jamais.

Mon appareil est un commutateur, pas un routeur — est-ce le même arbre de panne ?

Non. Les tickets de CPU élevé d'un commutateur sont bien plus souvent une tempête TC ou une boucle MSTP recalculant la topologie qu'un seul processus emballé — voir Switch CPU Utilization High: Finding What's Eating the Control Plane pour ce chemin spécifique plutôt que celui-ci.

Quelles versions de logiciel routeur prennent réellement en charge le flame graph ?

La capture debug system cpu performance et le fichier de flame graph qui en résulte sont nouveaux à partir de V600R024C10. Sur tout ce qui est antérieur, il n'y a pas de flame graph de repli — les champs de pile d'appels de thread imprimés directement dans display cpu-usage top sont l'outil équivalent pour ces versions.

Limites honnêtes de cette note

Limites honnêtes de cette note

Cette note s'articule autour du modèle de dépannage CPU/mémoire V600 du routeur Huawei série AR et de ses commandes display health / cpu-usage / memory statistics / handle-alloc, plus la capture de flame graph V600R024C10, tirés du propre manuel de maintenance AR de Huawei. Elle ne couvre pas une liste spécifique de causes racines de fuite mémoire — un handle en croissance nécessite toujours qu'un ingénieur support lise le flame graph ou la sortie handle-alloc et confirme ce qui retient réellement la mémoire. Sur un logiciel antérieur à V600R024C10, considérez les étapes de flame graph comme non applicables et fiez-vous plutôt à la vue de pile d'appels de thread.

Vous lisez un dump CPU ou mémoire et vous êtes bloqué ?

Envoyez-nous votre sortie display health / cpu-usage top, ou le fichier .unfold du flame graph, et nous vous aiderons à le lire.

WhatsApp avec un ingénieur →