Problemen met geheugen oplossen in IOS XE via callsite
Inhoud
Inleiding
In dit document wordt beschreven hoe u geheugenproblemen kunt oplossen in Cisco IOS® XE-apparaten zoals routers en switches voor een lekkende callsite.
Voorwaarden
Kennis van geheugenbeheer in Cisco IOS XE-softwaregebaseerde apparaten.
Gebruikte componenten
Dit document is niet beperkt tot specifieke software- en hardware-versies. Het is van toepassing op routing en switching van Cisco IOS XE-softwareplatforms.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Achtergrondinformatie
Het monitoren van het gebruik van het productiegeheugen van het apparaat voor deltaverhogingen en het bevestigen of dit wordt verwacht, is tijdrovend. In dit document wordt uitgelegd wat een callsite is en hoe het helpt geheugenproblemen snel op te lossen.
Opmerking: Dit document is voornamelijk gericht op het oplossen van problemen met het routeren van het Dynamic Random-Access Memory (DRAM)-geheugengebruik van de processor.
Wat is de callsite?
De callsite is een tag die wordt gebruikt door het Cisco Technical Assistance Center (TAC) om te controleren en bij te houden welke functies van broncode worden aangeroepen tijdens geheugentoewijzingen die zijn gemaakt door Cisco IOS-XE-gerelateerde processen.
Klanten kunnen deze tag leveren voordat ze een TAC-case openen voor een snellere oplossing en klanten kunnen ook helpen bij het debuggen ervan door de opdrachten die later in dit artikel worden gepresenteerd.
Diff-aanroepen en diff-bytes
Diff-oproepen bewaken het verschil tussen het aantal oproepen voor geheugentoewijzingen en deallocaties. Typisch, een hoog volume van diff-oproepen kan een geheugen-gerelateerde probleem betekenen. Dit gebeurt wanneer er buitensporige hoeveelheden diffs zijn, wat aangeeft dat het systeem geen geheugen vrijgeeft en toewijzingen zich ophopen.
Zowel diff-aanroepen als diff-bytes kunnen worden gezien met commandshow-processen en geheugenplatformboekhouding:
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
Het systeem heeft interne drempels voor geheugengebruik die geheugenwaarschuwingen en syslogs op kritisch niveau activeren. Het percentage geheugengebruik op basis van deze drempelwaarden kan worden weergegeven met behulp van de opdrachtregelmiddelen voor het weergaveplatform.
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#Opmerking: Dien een TAC-geval in om te bepalen of de diff-aanroepen of diff-bytes betrekking hebben op een bepaald proces. Over het algemeen, als er een laag vrij systeemgeheugen is zoals zichtbaar met de opdracht toont processen geheugenplatform gesorteerd, is het de moeite waard om verder te controleren.
Symptomen voor geheugenverbruik of lekproblemen
Wanneer er een probleem is met geheugenverbruik of lekken in Cisco IOS XE, wordt meestal een waarschuwing of een kritisch alarm gegenereerd, zoals:
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).Dit type alarm benadrukt waardevolle informatie als uitgangspunt voor de probleemoplossing:
- Datum en tijd van het ontvangen alarm
- Percentage gebruik
- Onderdeel beïnvloed
- Top Cisco IOS XE-processen die het systeem detecteerden als topconsumenten op basis van verschillende oproepen.
Opmerking: Het %PLATFORM-4-ELEMENT_WARNING-alarm is niet noodzakelijk een overtuigend gegevenspunt om de Root Cause Analysis (RCA) van een geheugenverbruiksprobleem te krijgen.
Opmerking: Er zijn andere symptomen en waarschuwingen voor geheugengebruik die zijn gekoppeld aan verschillende componenten, zoals Temporal File System (TMPFS), Quantum Flow Processor (QFP) en Cisco IOS daemon (IOSd), maar deze vallen buiten het bereik van dit document.
Opmerking: Dit document behandelt niet de probleemoplossing van SYS-2-MALLOCFAIL syslog-berichten die wijzen op geheugenproblemen onder Cisco IOS daemon (IOSd).
Scenario's voor probleemoplossing
Apparaat is gecrasht vanwege geheugenverlies
Wanneer het apparaat crasht als gevolg van een gebrek aan geheugenbronnen, is het belangrijk om de laatste logs vóór de crash te verifiëren om te bevestigen en te zien of het syslog-bericht %PLATFORM-4-ELEMENT_WAARSCHUWING: R0/0: smand: RP/0: Gebruikte geheugenwaarde X% hoger is dan waarschuwingsniveau Y% is aanwezig.
Opmerking: syslogs van de lokale DRAM-buffer worden gewist na een crash als gevolg van geheugenverlies, dus het controleren van archieflogs van de syslog-server voordat de crash-gebeurtenis is vereist. Als syslog-server nog niet is ingesteld, raadpleegt u Logboekregistratie configureren in Cisco IOS.
Opmerking: De %PLATFORM-4-ELEMENT_WAARSCHUWING: R0/0: smand: RP/0: Gebruikte geheugenwaarde X% overschrijdt waarschuwingsniveau Y% alarm na een crash kan ook worden gezien in de gedecodeerde Cisco IOS-tracelogs. Zie Trace Logs verzamelen en beheren met Unified Logging Enhancement voor meer informatie.
Door gebrek aan geheugen kreeg het systeem te maken met een crash. Er wordt een systeemrapport gegenereerd. Dit rapport is een .tar.gz-bestand met relevante gegevens die kunnen worden gebruikt om het geheugenprobleem te onderzoeken. Raadpleeg Problemen oplossen met systeemrapporten voor meer informatie.
Wanneer het systeemrapport wordt gedecomprimeerd, bevat het een directory met de naam maroon stats binnen de tmp-directory. De Maroon-status is een servicefaciliteit geïmplementeerd in code die geheugentoewijzingen en deallocaties bijhoudt in verschillende oproepen en bytes voor verschillende Cisco IOS XE-processen.
De momentopname van de kastanjestatistieken in het systeemrapport helpt bij het identificeren van een potentiële boosdoener callsite om het geheugenverbruik of lekprobleem RCA te bepalen of verder te debuggen en beter te begrijpen.
Opmerking: Het decoderen van de map met de kastanjestatus uit een systeemrapport kan alleen worden gedaan door TAC omdat deze interne en vertrouwelijke codefuncties bevat die de TAC-ingenieur helpen te begrijpen welke codefuncties het geheugen toewijzen. Dien een TAC-geval in en geef het systeemrapport op.
Opmerking: Houd er rekening mee dat het systeemrapport een goede hoeveelheid gegevens biedt om een geheugencrash te begrijpen als gevolg van geheugenverlies, maar in sommige gevallen is verdere geheugentracking, bewaking, foutopsporing en probleemoplossing nodig.
Apparaat is nog niet gecrasht, maar heeft waarschuwingen voor geheugengebruik
De opdracht toont platformbronnen, toont waarschuwingsdrempels en drempels voor kritisch geheugengebruik.
Opmerking: het is de beste manier om geheugengerelateerde uitvoeropdrachten te verzamelen om verder te debuggen, omdat afhankelijk van hoe snel het geheugenverbruik of lek kan gebeuren, het apparaat het risico loopt te crashen vanwege geheugenbronnen.
Opmerking: Wanneer waarschuwingen voor geheugengebruik worden weergegeven, kunt u een TAC-geval indienen en opdrachten geven die technische ondersteuning en
tonen tech-support geheugen dat de TAC ingenieur helpt om in eerste instantie triage van het probleem en mogelijk vinden van een RCA snel.
Wanneer het apparaat nog niet is gecrasht en het de geheugenalarmen in de lokale syslog-buffer genereert of via de monitoringtool van de syslog-server is ontvangen, verzamelt u de uitvoer van het showprocessen-geheugenplatform dat is gesorteerd om de bytes te bepalen die door het overtredende proces worden verbruikt, indien aanwezig.
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
Kijk in deze uitvoer naar de kolom Ingezetensgrootte (RSS). Dit geeft aan hoeveel kilobytes elk Cisco IOS XE-proces verbruikt.
Identificeer de callsite
Verzamel vervolgens de uitvoer van showprocessen en geheugenplatformboekhouding die de diff-aanroepen en bytewaarden voor verschillende processen toont. Meestal richten we ons op de grotere waarden.
De diff call bytes is een goede indicator om te bepalen of er een potentieel geheugenlek kan zijn, omdat het laat zien hoeveel bytes geheugen nog steeds door het systeem worden vastgehouden door een proces zonder terug te worden vrijgegeven aan het systeem.
Op basis van deze gegevens kunt u identificeren welke de callsite-tag is van het overtredende proces met de grotere diff-aanroepen en bytes-waarden.
De procesgeheugenplatformboekhouding volgt deze verschillende oproepen en bytes in de loop van de tijd. In sommige gevallen is een backtrace opgenomen aan de onderkant van deze opdrachtuitvoer. Dit is belangrijk voor TAC-ingenieurs, omdat dergelijke backtrace wordt gedecodeerd met behulp van interne hulpmiddelen en helpt bij het bepalen welke functies van code een potentieel geheugenlek kunnen veroorzaken.
Opmerking: Verdere foutopsporing voor een proces is vaak nodig als de opdracht tonen proces geheugen platform accounting niet voldoende informatie om een probleem met geheugenlekken op te lossen.
Zie ook De callsite debuggen uit dit document voor een secundaire methode om de callsite te identificeren.
Verwerk geheugenverbruik in modules, databases en berichten
Het verzamelen van deze opdrachten voor een specifiek Cisco IOS XE-proces kan nodig zijn om een geheugenlek in het Cisco IOS XE-proces verder op te sporen:
# 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_ Deze commando-uitgangen vullen het onderzoek van een geheugenlek veroorzaakt door een proces aan en zijn vaak vereist als de initiële basis triage-opdrachten niet voldoende informatie bieden.
Debug van de callsite
Een secundaire methode om de callsite te identificeren, is om deze te debuggen. Deze commando's zijn vereist:
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 De eerste opdracht maakt het debuggen van toewijzingen voor de callsites van een proces mogelijk. In latere versies is deze opdracht standaard ingeschakeld en heeft deze geen invloed op de service.
De opdracht Toon platformsoftwaregeheugen <proces> <locatie> toegewezen callsite-opdracht biedt een tabel met de callsites voor dat proces en de verschillende oproepen en bytes voor elke callsite. Hier tonen we bijvoorbeeld de uitvoer voor het Cisco IOS-proces, maar deze kan worden verzameld voor elk ander proces:
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
Opmerking: De opdracht tonen platte zachte geheugen <process> <location> alloc callsite bri moet meerdere keren worden uitgevoerd in de tijd totdat het vinden van de diff oproep of bytes kolom verhogen als het zou een indicator dat het systeem is het vasthouden van een dergelijk geheugen zonder het vrij te geven.
Zodra is vastgesteld dat de callsite lekt, moet de opdracht debug platform software memory <process> <location> alloc backtrace start <callsite> depth 10 voor die callsite worden uitgevoerd. Deze opdracht kan op zijn plaats worden gelaten en heeft geen invloed op de service.
Het uitvoeren van de opdracht show plat soft memory <process> <location> alloc callsite bri opnieuw totdat het zien van diff calls/bytes verhogingen is nog steeds nodig na het inschakelen van de debug van de geïdentificeerde callsite, dit om de functies van code toewijzend geheugen voor die callsite te volgen. Later kan de backtrace worden verzameld met behulp van show platform software memory <process> <location> alloc backtrace, bijvoorbeeld:
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: 70Opmerking: Geef deze uitvoer aan TAC voor het decoderen van de backtrace, dan kan TAC-ingenieur het gedrag in code verifiëren, bepalen of er een bestaand defect is of het gedrag beter begrijpen. Indien nodig kan TAC het ontwikkelaarsteam bereiken.
Opmerking: zorg ervoor dat de software up-to-date is. In het geval dat een nieuw softwaredefect wordt gevonden, kan TAC samenwerken met het ontwikkelaarsteam om de toestand verder te debuggen en te onderzoeken.
Gerelateerde artikelen en documentatie
Revisiegeschiedenis
| Revisie | Publicatiedatum | Opmerkingen |
|---|---|---|
1.0 |
17-Oct-2025
|
Eerste vrijgave |
FeedbackContact Cisco
- Een ondersteuningscase openen
- (Vereist een Cisco-servicecontract)