Résolution des problèmes de mémoire dans IOS XE via Callsite
Table des matières
Introduction
Ce document décrit comment dépanner les problèmes de mémoire dans les périphériques basés sur Cisco IOS® XE tels que les routeurs et les commutateurs pour un site d'appel qui fuit.
Conditions préalables
Connaissance de la gestion de la mémoire dans les périphériques basés sur le logiciel Cisco IOS XE.
Composants utilisés
Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques. Il s'applique aux plates-formes basées sur le logiciel Cisco IOS XE de routage et de commutation.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.
Informations générales
La surveillance de l'utilisation de la mémoire de production du périphérique pour les incréments delta et la confirmation de son utilisation prévue prennent du temps. Ce document explique ce qu'est un site d'appel et comment il aide à résoudre rapidement les problèmes de mémoire.
Remarque : ce document est principalement axé sur le dépannage de l'utilisation de la mémoire DRAM (Dynamic Random-Access Memory) du processeur de routage.
Qu'est-ce que Callsite ?
Le site d'appel est une balise utilisée par le centre d'assistance technique de Cisco (TAC) pour vérifier et suivre les fonctions du code source qui sont appelées pendant les allocations de mémoire effectuées par les processus liés à Cisco IOS-XE.
Les clients peuvent fournir cette balise avant d'ouvrir un dossier TAC pour une résolution plus rapide et les clients peuvent également aider au débogage par les commandes présentées plus loin dans cet article.
Appels diff et octets diff
Les appels de différence surveillent la disparité entre le nombre d'appels pour les allocations de mémoire et les désallocations. En général, un volume élevé d'appels diff peut indiquer un problème lié à la mémoire. Cela se produit lorsqu'il y a des quantités excessives de diffs, ce qui indique que le système ne libère pas de mémoire et que les allocations s'accumulent.
Les appels diff et les octets diff peuvent être vus avec la commande show processes memory platform accounting :
test1#show processes memory platform accounting
Hourly Stats
process callsite_ID(bytes) max_diff_bytes callsite_ID(calls) max_diff_calls tracekey timestamp(UTC)
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
sessmgrd_rp_0 F8E78C86E08C8003 1579683 E6A19D3ED0064000 12269 1#90e06c15b54d23761b2b3b480e5fd704 2025-05-28 05:30
cli_agent_rp_0 A5E99693AA3B8004 1268440 5D11C89CA87A8003 3197 1#3afb1165961ee7daf4af986e47f2f32c 2025-05-28 05:40
smand_rp_0 3DFF8F3C424F400A 918144 C34A609190E3C001 420 1#51a1581a8ac23e847e66fe8f268c66d1 2025-05-29 06:31
Le système dispose de seuils d'utilisation de la mémoire interne qui déclenchent des avertissements de mémoire et des syslogs de niveau critique. Le pourcentage d'utilisation de la mémoire basé sur ces seuils peut être affiché à l'aide de la commande show platform resources.
test1#show platform resources
**State Acronym: H - Healthy, W - Warning, C - Critical
Resource Usage Max Warning Critical State
----------------------------------------------------------------------------------------------------
RP0 (ok, active) H
Control Processor 1.17% 100% 80% 90% H
DRAM 2639MB(34%) 7753MB 88% 93% H
bootflash 856MB(13%) 6338MB 88% 93% H
harddisk 0MB(0%) 0MB 88% 93% H
ESP0(ok, active) H
QFP H
TCAM 10cells(0%) 131072cells 65% 85% H
DRAM 89761KB(2%) 3670016KB 85% 95% H
IRAM 13525KB(10%) 131072KB 85% 95% H
CPU Utilization 1.00% 100% 90% 95% H
Crypto Utilization 3.00% 100% 90% 95% H
Pkt Buf Mem (0) 67KB(0%) 524288KB 85% 95% H
test1#Remarque : Déposez un dossier TAC pour déterminer si les appels diff ou les octets diff concernent un processus particulier. En général, si la mémoire système disponible est faible, comme le montre la commande show processes memory platform triée, il vaut la peine de vérifier davantage.
Symptômes des problèmes de consommation de mémoire ou de fuite
En cas de problème de consommation ou de fuite de mémoire côté Cisco IOS XE, un avertissement ou une alarme critique est généralement généré, par exemple :
Nov 22 11:37:16.770: %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: RP/0: Used Memory value 89% exceeds warning level 88%. Top memory allocators are: Process: iomd_cc_0. Tracekey: 1#7eed26e49896115921b704a6d9780e72 Callsite ID: 4163698691 (diff_call: 395435). Process: iomd_cc_0. Tracekey: 1#7eed26e49896115921b704a6d9780e72 Callsite ID: 4163698691 (diff_call: 29). Process: btman_rp_0. Tracekey: 1#e7e4075661e7b1cbf867dc220f1b120c Callsite ID: 407738370 (diff_call: 23).Ce type d'alarme met en évidence des informations précieuses comme point de départ pour le dépannage :
- Date et heure de réception de l'alarme
- Pourcentage d'utilisation
- Composant impacté
- Principaux processus Cisco IOS XE que le système a détectés comme principaux consommateurs sur la base d'appels diff.
Remarque : L'alarme %PLATFORM-4-ELEMENT_WARNING n'est pas nécessairement un point de données concluant pour obtenir l'analyse de la cause première (RCA) d'un problème de consommation de mémoire.
Remarque : Il existe d'autres types de symptômes et d'alarmes d'utilisation de la mémoire associés à différents composants tels que Temporal File System (TMPFS), Quantum Flow Processor (QFP) et Cisco IOS daemon (IOSd), mais ceux-ci ne sont pas abordés dans ce document.
Remarque : Ce document ne couvre pas le dépannage des messages syslog SYS-2-MALLOCFAIL qui indiquent un problème de mémoire sous le démon Cisco IOS (IOSd).
Scénarios de dépannage
Le périphérique est tombé en panne en raison d'une mémoire insuffisante
Lorsque le périphérique tombe en panne en raison de ressources mémoire insuffisantes, il est important de vérifier les derniers journaux avant la panne afin de confirmer et de voir si le message syslog %PLATFORM-4-ELEMENT_WARNING: R0/0: smand : RP/0 : La valeur de mémoire utilisée X% dépasse le niveau d'avertissement Y% est présent.
Remarque : Notez que les syslogs de la mémoire tampon DRAM locale sont effacés après une panne due à un manque de mémoire, donc la vérification des journaux d'archive à partir du serveur syslog avant l'événement de panne est nécessaire. Si le serveur syslog n'est pas encore configuré, référez-vous à Comment configurer la journalisation dans Cisco IOS.
Remarque : %PLATFORM-4-ELEMENT_WARNING : R0/0: smand : RP/0 : La valeur de mémoire utilisée X% dépasse le niveau d'avertissement Y% alarme après un événement de panne peut également être vu dans les journaux de suivi Cisco IOS décodés. Référez-vous à Collecter et gérer les journaux de suivi avec l'amélioration de la journalisation unifiée pour plus d'informations.
En raison d'une mémoire insuffisante, le système a rencontré une panne. Par conséquent, un rapport système est généré. Ce rapport est un fichier .tar.gz contenant des données pertinentes qui peuvent être utilisées pour étudier le problème de mémoire. Référez-vous à Dépannage à l'aide des rapports système pour plus d'informations.
Une fois décompressé, le rapport système contient un répertoire appelé statistiques marron dans le répertoire tmp. L'état de la bande passante est une fonction de facilité de maintenance mise en oeuvre dans le code qui suit les allocations et les désallocations de mémoire dans les appels et les octets différents pour les différents processus Cisco IOS XE.
L'instantané de statistiques marron contient dans le rapport système, aide à identifier un site d'appel coupable potentiel pour déterminer la consommation de mémoire ou le problème de fuite RCA ou le déboguer davantage et mieux le comprendre.
Remarque : Le TAC ne peut décoder le répertoire de statistiques marron à partir d'un rapport système que s'il contient des fonctions internes et confidentielles de code qui aident l'ingénieur TAC à comprendre quelles fonctions de code allouent la mémoire. Veuillez déposer un dossier auprès du centre d'assistance technique et fournir le rapport système.
Remarque : Gardez à l'esprit que le rapport système fournit une bonne quantité de données pour comprendre une panne de mémoire due à un manque de mémoire, cependant, dans certains cas, un suivi, une surveillance, un débogage et un dépannage supplémentaires de la mémoire sont nécessaires.
Le périphérique n'est pas encore tombé en panne, mais comporte des avertissements d'utilisation de mémoire
La commande show platform resources, affiche les seuils d'avertissement et d'utilisation critique de la mémoire.
Remarque : il est recommandé de collecter les commandes de sortie relatives à la mémoire afin de poursuivre le débogage, car selon la vitesse à laquelle la consommation ou la fuite de mémoire peut se produire, le périphérique peut être exposé à un risque de panne en raison de ressources mémoire insuffisantes.
Remarque : Lorsque des avertissements d'utilisation de la mémoire s'affichent, vous pouvez créer un dossier TAC et fournir les commandes show tech-support et
Montrez la mémoire du support technique qui aide l'ingénieur du centre d'assistance technique à commencer par trier le problème et éventuellement à trouver rapidement une RCA.
Lorsque le périphérique n'est pas encore tombé en panne et qu'il génère les alarmes de mémoire dans le tampon syslog local ou qu'il est reçu du serveur syslog via l'outil de surveillance, rassemblez la sortie de show processes memory platform triée pour déterminer les octets consommés par le processus fautif, le cas échéant.
Router#show processes memory platform sorted
System memory: 4027884K total, 2580612K used, 1447272K free,
Lowest: 1447272K
Pid Text Data Stack Dynamic RSS Total Name
--------------------------------------------------------------------------------
21240 263436 858000 136 308 858000 3632460 linux_iosd-imag
27232 12877 195460 136 23592 195460 2231316 fman_fp_image
26797 90 157260 136 22308 157260 1741996 cpp_cp_svr
19194 7325 102756 136 2376 102756 1318608 fman_rp
27179 18745 242708 136 448 242708 1160248 qfp-ucode-utah
Dans cette sortie, regardez la colonne Resident Set Size (RSS). Il s'agit d'un indicateur du nombre de kilo-octets consommés par chaque processus Cisco IOS XE.
Identifier le site d'appel
Ensuite, rassemblez le résultat de la comptabilisation de la plate-forme mémoire de show processes qui montre les appels diff et les valeurs d'octets pour différents processus. Habituellement, nous nous concentrons sur les valeurs plus grandes.
Les octets d'appel diff sont un bon indicateur pour déterminer s'il peut y avoir une fuite de mémoire potentielle, car ils indiquent la quantité d'octets de mémoire encore en attente par le système par un processus sans être libérés dans le système.
Sur la base de ces données, vous pouvez identifier quelle est la balise callsite du processus fautif qui a les plus grands appels diff et les valeurs d'octets.
La commande show process memory platform accounting effectue le suivi de ces appels et octets de différence dans le temps. Dans certains cas, une commande backtrace est incluse au bas de cette sortie de commande. Ceci est important pour l'ingénieur du TAC, car cette trace est décodée à l'aide d'outils internes et aide à déterminer quelles fonctions du code peuvent provoquer une fuite de mémoire potentielle.
Remarque : Un débogage supplémentaire pour un processus est souvent nécessaire si la commande show process memory platform accounting ne fournit pas suffisamment d'informations pour dépanner un problème de fuite de mémoire.
Voir aussi Debug the Callsite from this document pour une méthode secondaire pour identifier le site d'appel.
Consommation de mémoire de traitement dans les modules, les bases de données et la messagerie
La collecte de ces commandes pour un processus Cisco IOS XE spécifique peut être nécessaire pour déboguer davantage une fuite de mémoire du processus Cisco IOS XE :
# Allocations and frees per module
show platform software memory
show platform software memory bri
# Database diff and entries statistics
show platform software memory database | ex diff:0
show platform software memory database bri | ex _0_
# Messaging diff and entries statistics
show platform software memory messaging | ex diff:0
show platform software memory messaging brief | ex _0_ Ces sorties de commande complètent l'investigation d'une fuite de mémoire causée par un processus et sont souvent requises si les commandes de triage de base initiales ne fournissent pas suffisamment d'informations.
Déboguer le site d'appel
Une méthode secondaire pour identifier le site d'appel consiste à le déboguer. Ces commandes sont requises :
debug platform software memory alloc callsite start
show platform software memory alloc callsite brief
debug platform software memory alloc backtrace start depth 10
show platform software memory alloc backtrace La première commande active le débogage des allocations pour les sites d'appels d'un processus. Dans les versions ultérieures, cette commande est activée par défaut et n'a pas d'impact sur le service.
La commande show platform software memory <process> <location> alloc callsite brief fournit un tableau qui montre les sites d'appel pour ce processus et les appels et octets de différence pour chaque site d'appel. Par exemple, nous affichons ici le résultat du processus Cisco IOS, mais il peut être collecté pour tout autre processus :
test1# show platform software memory ios r0 alloc callsite brief
The current tracekey is : 1#b1ba773f123f8d990fd84c82c1d0e1d3
callsite thread diff_byte diff_call
----------------------------------------------------------------
3DFF8F3C424F4004 4115 57384 1
ABB2D8F932038000 4115 57360 1
3869885745FC8000 4115 16960 1
DF884D58A8EF0004 4115 8208 1
DF884D58A8EF0008 4115 8208 1
FAE69298A17B8000 4115 4243 165
FAE69298A17B8001 4115 2640 165
FAE69298A17B8002 4115 1958 12
Remarque : La commande show plat soft memory <process> <location> alloc callsite bri doit être exécutée plusieurs fois au cours du temps jusqu'à ce que la colonne diff call ou bytes augmente, car elle indique que le système conserve cette mémoire sans la libérer.
Une fois le site d'appel identifié comme fuyant, la commande debug platform software memory <process> <location> alloc backtrace start <callsite> depth 10 doit être exécutée pour ce site d'appel. Cette commande peut rester en place et n'a pas d'impact sur le service.
L'exécution de la commande show plat soft memory <process> <location> alloc callsite bri à nouveau jusqu'à ce que des augmentations d'appels/octets diff soient toujours nécessaires après l'activation du débogage du site d'appel identifié, ceci pour suivre les fonctions d'allocation de code de mémoire pour ce site d'appel. Par la suite, le backtrace peut être collecté en utilisant show platform software memory <process> <location> alloc backtrace, par exemple :
show platform software memory install-manager switch active R0 alloc back
backtrace: 1#83e58872a4792de086bf7191551098d7 maroon:7FCBACB87000+4642 maroon:7FCBACB87000+579C repm_core:7FCBB1F29000+1E146 avl:7FCBB4005000+2989 repm_core:7FCBB1F29000+1DAF6 repm_core:7FCBB1F29000+1BADF repm_core:7FCBB1F29000+37BA6 repm_core:7FCBB1F29000+2A341 tdldb_assist_no_dbdm:7FCBB5EDE000+416E
callsite: 7BD5593C00E30000, thread_id: 15556
allocs: 70, frees: 0, call_diff: 70Remarque : Fournissez ce résultat au TAC pour décoder la trace arrière, puis l'ingénieur TAC peut vérifier le comportement dans le code, déterminer s'il y a un défaut existant ou mieux comprendre le comportement. Si nécessaire, le TAC peut contacter l'équipe de développeurs.
Remarque : assurez-vous que le logiciel est à jour. Si un nouveau défaut logiciel est détecté, le centre d'assistance technique peut travailler avec l'équipe de développeurs pour poursuivre le débogage et étudier la condition.
Articles et documentation associés
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
1.0 |
17-Oct-2025
|
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)