Inhoud

Inleiding

Voorwaarden

Gebruikte componenten

Achtergrondinformatie

Wat is de callsite?

Diff-aanroepen en diff-bytes

Symptomen voor geheugenverbruik of lekproblemen

Scenario's voor probleemoplossing

Apparaat is gecrasht vanwege geheugenverlies

Apparaat is nog niet gecrasht, maar heeft waarschuwingen voor geheugengebruik

Identificeer de callsite

Verwerk geheugenverbruik in modules, databases en berichten

Debug van de callsite

Gerelateerde artikelen en documentatie

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

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

- ASR 1000-reeks Router Memory Problemen oplossen

- Onderzoek het geheugengebruik van IOS-XE

- Problemen met geheugengebruik melden via EEM

- Gids voor geheugenprobleemoplossing voor ISR's uit de Cisco 4000-reeks