Risoluzione dei problemi di memoria in IOS XE tramite callsite
Sommario
Introduzione
In questo documento viene descritto come risolvere i problemi di memoria nei dispositivi basati su Cisco IOS® XE, come router e switch, per risolvere una perdita di sito di chiamata.
Prerequisiti
Conoscenza della gestione della memoria nei dispositivi basati su software Cisco IOS XE.
Componenti usati
Il documento può essere consultato per tutte le versioni software o hardware. Si applica alle piattaforme basate su software Cisco IOS XE di routing e switching.
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
Monitorare l'utilizzo della memoria di produzione del dispositivo per gli incrementi delta e verificare se è previsto è un processo che richiede tempo. Questo documento spiega che cos'è un sito di chiamata e come aiuta a risolvere rapidamente i problemi di memoria.
Nota: questo documento si concentra principalmente sulla risoluzione dei problemi relativi all'utilizzo della memoria DRAM (Dynamic Random Access Memory) da parte del processore di routing.
Che cos'è il sito chiamate?
Il sito chiamate è un tag utilizzato da Cisco Technical Assistance Center (TAC) per verificare e tenere traccia delle funzioni del codice sorgente chiamate durante le allocazioni di memoria eseguite dai processi correlati a Cisco IOS-XE.
I clienti possono fornire questo tag prima di aprire una richiesta TAC per una risoluzione più rapida e possono inoltre contribuire al debug tramite i comandi presentati più avanti in questo articolo.
Chiamate diff e byte diff
Le chiamate diff monitorano la disparità tra il numero di chiamate per l'allocazione di memoria e le deallocazioni. In genere, un volume elevato di chiamate diff può indicare un problema relativo alla memoria. Questo si verifica quando vi sono quantità eccessive di diff, indicando che il sistema non sta rilasciando memoria e le allocazioni stanno accumulando.
È possibile visualizzare sia le chiamate diff che i byte diff con il comando 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
Il sistema dispone di soglie interne di utilizzo della memoria che attivano avvisi di memoria e syslog di livello critico. La percentuale di utilizzo della memoria basata su queste soglie può essere visualizzata utilizzando il comando 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#Nota: Archivia un caso TAC per determinare se le chiamate diff o i byte diff sono relativi a un particolare processo. In genere, se è presente una quantità insufficiente di memoria di sistema visibile con il comando show processes memory platform, è opportuno verificare ulteriormente.
Sintomi per il consumo di memoria o problemi di perdita
Quando si verifica un problema di consumo di memoria o di perdita sul lato Cisco IOS XE, in genere viene generato un allarme di avvertenza o critico, ad esempio:
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).Questo tipo di allarme evidenzia le informazioni importanti come punto di partenza per la risoluzione dei problemi:
- Data e ora di ricezione dell'allarme
- Percentuale utilizzo
- Componente interessato
- Primi processi Cisco IOS XE rilevati dal sistema come principali consumer in base alle chiamate diff.
Nota: L'allarme %PLATFORM-4-ELEMENT_WARNING non è necessariamente un punto dati conclusivo per ottenere l'analisi della causa principale (RCA) di un problema di utilizzo della memoria.
Nota: Esistono altri tipi di sintomi e allarmi per l'utilizzo della memoria associati a diversi componenti, ad esempio Temporal File System (TMPFS), Quantum Flow Processor (QFP) e Cisco IOS Daemon (IOSd), ma non rientrano nell'ambito di questo documento.
Nota: Questo documento non descrive la risoluzione dei problemi dei messaggi di syslog SYS-2-MALLOCFAIL che indicano problemi di memoria nel daemon Cisco IOS (IOSd).
Risoluzione dei problemi
Arresto anomalo del dispositivo a causa di memoria insufficiente
Quando il dispositivo si blocca a causa di risorse di memoria insufficienti, è importante verificare gli ultimi log prima dell'arresto anomalo per verificare se il messaggio syslog %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: RP/0: Il valore della memoria utilizzata X% supera il livello di avviso Y%.
Nota: Si noti che i syslog dal buffer DRAM locale vengono cancellati dopo un arresto anomalo dovuto a memoria insufficiente, pertanto è necessario controllare i log di archivio dal server syslog prima dell'evento di arresto anomalo. Se il server syslog non è ancora stato configurato, consultare il documento sulla configurazione della registrazione in Cisco IOS.
Nota: %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: RP/0: Il valore X% della memoria utilizzata supera il livello di avviso Y% quando un evento di crash può essere rilevato anche nei tracelog decodificati di Cisco IOS. per ulteriori informazioni, fare riferimento a Raccogli e gestisci log di traccia con il miglioramento della registrazione unificata.
Memoria insufficiente. Il sistema è stato bloccato. Di conseguenza, viene generato un report di sistema. Questo report è un file .tar.gz contenente dati pertinenti che possono essere utilizzati per analizzare il problema relativo alla memoria. Per ulteriori informazioni, fare riferimento a Risoluzione dei problemi relativi all'utilizzo dei report di sistema.
Quando viene decompresso, il report di sistema contiene una directory denominata maroon status all'interno della directory tmp. Lo stato bordeaux è una funzionalità di supporto implementata nel codice che tiene traccia delle allocazioni di memoria e delle deallocazioni nelle chiamate diff e nei byte per diversi processi Cisco IOS XE.
Lo snapshot delle statistiche bordeaux contiene all'interno del report di sistema e consente di identificare un potenziale sito di chiamate responsabile per determinare il consumo di memoria o il problema di perdita RCA oppure di eseguirne il debug per comprenderlo meglio.
Nota: La decodifica della directory maroon status da un report di sistema può essere eseguita solo da TAC, in quanto contiene funzioni di codice interne e riservate che consentono al tecnico TAC di comprendere quali funzioni di codice stanno allocando la memoria. Presentare una richiesta TAC e fornire il rapporto sul sistema.
Nota: Tenere presente che il report di sistema fornisce una buona quantità di dati per comprendere un arresto anomalo della memoria dovuto a memoria insufficiente. In alcuni casi, tuttavia, è necessario eseguire ulteriori operazioni di monitoraggio, debug e risoluzione dei problemi.
Il dispositivo non è stato ancora arrestato in modo anomalo ma presenta avvisi sull'utilizzo della memoria
Il comando show platform resources mostra le soglie di avvertenza e di utilizzo critico della memoria.
Nota: è buona norma raccogliere i comandi di output relativi alla memoria per eseguire ulteriori operazioni di debug. A seconda della velocità di utilizzo della memoria o di perdita, il dispositivo potrebbe essere a rischio di arresto anomalo a causa di risorse di memoria esaurite.
Nota: Quando vengono visualizzati avvisi sull'utilizzo della memoria, è possibile archiviare una richiesta TAC e fornire comandi per mostrare il supporto tecnico e
mostrare la memoria di supporto tecnico che aiuta il tecnico TAC a valutare inizialmente il problema e potenzialmente a trovare immediatamente un RCA.
Quando il dispositivo non si è ancora arrestato e sta generando gli allarmi di memoria nel buffer syslog locale o ricevuti dal server syslog tramite lo strumento di monitoraggio, raccogliere l'output della piattaforma di memoria show PROCESSES ordinata per determinare gli eventuali byte utilizzati dal processo in conflitto.
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
In questo output, esaminare la colonna RSS (Resident Set Size). Questo è un indicatore di quanti kilobyte ogni processo Cisco IOS XE sta consumando.
Identifica il sito chiamante
Raccogliere quindi l'output di show processes memory platform accounting che mostra le chiamate diff e i valori byte per i diversi processi. Di solito ci concentriamo sui valori più grandi.
I byte delle chiamate diff sono un buon indicatore per determinare se può esserci una potenziale perdita di memoria, in quanto mostrano la quantità di byte di memoria ancora bloccati dal sistema da un processo senza essere rilasciati nuovamente al sistema.
In base a questi dati, è possibile identificare quale sia il tag del sito di chiamata del processo che causa l'errore e che abbia i valori più grandi per le chiamate diff e i byte.
L'accounting show process memory platform tiene traccia delle chiamate diff e dei byte nel tempo. In alcuni casi, nella parte inferiore dell'output del comando è inclusa una traccia di ritorno. Ciò è importante per il tecnico TAC in quanto tale backtrace viene decodificata utilizzando strumenti interni e aiuta a determinare quali funzioni del codice possono causare una potenziale perdita di memoria.
Nota: È spesso necessario eseguire ulteriori operazioni di debug per un processo se il comando show process memory platform accounting non fornisce informazioni sufficienti per risolvere un problema di perdita di memoria.
Vedere anche Debug del sito chiamate da questo documento per un metodo secondario per identificare il sito chiamate.
Utilizzo della memoria di processo in moduli, database e messaggi
La raccolta di questi comandi per un processo Cisco IOS XE specifico può essere necessaria per eseguire ulteriormente il debug di una perdita di memoria nel processo 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_ Questi output dei comandi completano l'analisi di una perdita di memoria causata da un processo e sono spesso richiesti se i comandi iniziali di triage di base non forniscono informazioni sufficienti.
Debug del sito chiamante
Un metodo secondario per identificare il sito chiamante è il debug. Questi comandi sono obbligatori:
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 Il primo comando consente il debug delle allocazioni per i siti di chiamata di un processo. Nelle versioni più recenti, questo comando è abilitato per impostazione predefinita e non influisce sul servizio.
Il comando show platform software memory <processo> <posizione> alloc callsite brief fornisce una tabella che mostra i callsite per quel processo e le chiamate e i byte diff per ciascun callsite. Ad esempio, qui viene mostrato l'output del processo Cisco IOS, ma è possibile recuperarlo per qualsiasi altro processo:
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
Nota: Il comando show plat soft memory <process> <location> alloc callsite bri deve essere eseguito più volte nel tempo fino a quando la chiamata diff o la colonna bytes non aumenta, in quanto sarebbe un indicatore che il sistema tiene tale memoria senza rilasciarla.
Una volta identificato il sito di chiamata con perdita, è necessario eseguire il comando debug platform software memory <processo> <posizione> alloc backtrace start <sito di chiamata> depth 10 per tale sito di chiamata. Questo comando può essere lasciato sul posto e non influisce sul servizio.
Eseguire di nuovo il comando show plat soft memory <processo> <posizione> alloc callsite bri finché non si verificano aumenti delle chiamate/byte diff dopo aver abilitato il debug del sito chiamate identificato, per tenere traccia delle funzioni di allocazione della memoria per tale sito chiamate. In seguito, è possibile raccogliere la traccia di ritorno usando il comando show platform software memory <processo> <posizione> alloc backtrace, ad esempio:
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: 70Nota: Fornire questo output a TAC per decodificare la backtrace, quindi TAC Engineer può verificare il comportamento nel codice, determinare se esiste un difetto o comprenderne meglio il comportamento. Se necessario, TAC può raggiungere il team di sviluppo.
Nota: assicurarsi che il software sia aggiornato. Se viene rilevato un nuovo difetto del software, TAC può collaborare con il team dello sviluppatore per eseguire ulteriormente il debug e analizzare la condizione.
Articoli e documentazione correlati
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
1.0 |
17-Oct-2025
|
Versione iniziale |
Feedback