Fehlerbehebung bei Speicherproblemen in IOS XE über Callsite
Inhalt
Einleitung
Dieses Dokument beschreibt die Fehlerbehebung bei Speicherproblemen auf Cisco IOS® XE-basierten Geräten wie Routern und Switches für einen undichten Callsite.
Voraussetzungen
Kenntnisse im Speichermanagement auf softwarebasierten Cisco IOS XE-Geräten
Verwendete Komponenten
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt. Sie gilt für Routing und Switching auf der Basis der Cisco IOS XE Software.
Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Überwachung der Nutzung des Produktionsspeichers des Geräts für Delta-Inkremente und Bestätigung, ob dies voraussichtlich zeitaufwendig ist In diesem Dokument wird erläutert, was ein Anrufstandort ist und wie er dazu beiträgt, Speicherprobleme schnell zu beheben.
Hinweis: Dieses Dokument befasst sich hauptsächlich mit der Fehlerbehebung bei der Verwendung von dynamischem RAM-Speicher (DRAM) des Routingprozessors.
Was ist die Callsite?
Der Callsite ist ein Tag, der vom Cisco Technical Assistance Center (TAC) verwendet wird, um zu überprüfen und nachzuverfolgen, welche Funktionen des Quellcodes bei Speicherzuweisungen durch Prozesse im Zusammenhang mit Cisco IOS-XE aufgerufen werden.
Kunden können diesen Tag bereitstellen, bevor sie ein TAC-Ticket erstellen, um die Problembehebung zu beschleunigen, und Kunden können ihn mithilfe der später in diesem Artikel vorgestellten Befehle debuggen.
Diff-Anrufe und Diff-Bytes
Diff-Aufrufe überwachen die Diskrepanz zwischen der Anzahl von Aufrufen für Speicherzuweisungen und Deallocations. In der Regel kann eine große Anzahl von Diff-Aufrufen auf ein speicherbezogenes Problem hinweisen. Dies tritt auf, wenn zu viele Unterschiede bestehen, was darauf hinweist, dass das System keinen Speicher freigibt und sich die Zuweisungen ansammeln.
Sowohl Diff-Aufrufe als auch Diff-Bytes können mit commandShow-Prozessen für die Speicherplattform-Accounting angezeigt werden:
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
Das System verfügt über interne Grenzwerte für die Speichernutzung, die Speicherwarnungen und Syslogs auf kritischer Ebene auslösen. Der prozentuale Anteil der Speichernutzung, der auf diesen Grenzwerten basiert, kann mit dem Befehl show platform resources angezeigt werden.
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#Anmerkung: Erstellen Sie ein TAC-Ticket, um festzustellen, ob Diff-Anrufe oder Diff-Bytes einen bestimmten Prozess betreffen. Im Allgemeinen, wenn es wenig freien Systemspeicher wie sichtbar mit dem Befehl show Prozesse Speicherplattform sortiert, lohnt es sich, weiter zu prüfen.
Symptome bei Speicherverbrauch oder Leckproblemen
Tritt auf der Cisco IOS XE-Seite ein Problem mit dem Speicherverbrauch oder ein Leck auf, wird in der Regel eine Warnung oder ein kritischer Alarm generiert, z. B.:
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).Dieser Alarmtyp hebt wertvolle Informationen als Ausgangspunkt für die Fehlerbehebung hervor:
- Datum und Uhrzeit des eingegangenen Alarms
- Nutzung in Prozent
- Betroffene Komponente
- Wichtigste Cisco IOS XE-Prozesse, die vom System aufgrund von Diff-Anrufen als Top-Kunden erkannt wurden
Anmerkung: Der %PLATFORM-4-ELEMENT_WARNING-Alarm ist nicht unbedingt ein aussagekräftiger Datenpunkt, um die Ursachenanalyse (Root Cause Analysis, RCA) eines Problems mit der Speicherbelegung zu erhalten.
Anmerkung: Es gibt andere Symptome und Alarme bei der Speichernutzung, die mit verschiedenen Komponenten verbunden sind, wie TMPFS (Temporal File System), QFP (Quantum Flow Processor) und IOS (Cisco IOS Daemon). Diese werden jedoch nicht in diesem Dokument behandelt.
Anmerkung: Dieses Dokument behandelt nicht die Fehlerbehebung von SYS-2-MALLOCFAIL-Syslog-Meldungen, die auf ein Speicherproblem unter dem Cisco IOS-Daemon (IOSd) hinweisen.
Fehlerbehebungsszenarien
Das Gerät ist aufgrund von zu wenig Speicher abgestürzt.
Wenn das Gerät aufgrund von Speichermangel abstürzt, müssen die letzten Protokolle vor dem Absturz überprüft werden, um zu überprüfen, ob die Syslog-Meldung %PLATFORM-4-ELEMENT_WARNING: R0/0: smand: UVP/0: Verwendeter Speicherwert X% überschreitet die Warnstufe Y% ist vorhanden.
Anmerkung: Beachten Sie, dass Syslogs aus dem lokalen DRAM-Puffer nach einem Absturz aufgrund von Speichermangel gelöscht werden. Überprüfen Sie daher die Archivprotokolle vom Syslog-Server, bevor das Absturzereignis erforderlich ist. Wenn der Syslog-Server noch nicht eingerichtet ist, finden Sie weitere Informationen unter How to configure logging in Cisco IOS (Konfigurieren der Protokollierung in Cisco IOS).
Anmerkung: %PLATFORM-4-ELEMENT_WARNUNG: R0/0: smand: UVP/0: Der Wert des verwendeten Speichers X% überschreitet den Warnzustand Y% Alarm nach einem Absturz kann auch in den decodierten Cisco IOS-Ablaufverfolgungsprotokollen angezeigt werden. Weitere Informationen finden Sie unter Sammeln und Verwalten von Ablaufverfolgungsprotokollen mit Unified Logging Enhancement.
Aufgrund des unzureichenden Speichers kam es zu einem Systemabsturz. Folglich wird ein Systembericht erstellt. Dieser Bericht ist eine .tar.gz-Datei, die relevante Daten enthält, die zur Untersuchung des Speicherproblems verwendet werden können. Weitere Informationen finden Sie unter Fehlerbehebung mit Systemberichten.
Wenn der Systembericht dekomprimiert wird, enthält er ein Verzeichnis namens maroon stats im tmp-Verzeichnis. Die maroon stats ist eine im Code implementierte Funktionalität, mit der Speicherzuweisungen und Speicherdepositionen in Diff-Aufrufen und Bytes für verschiedene Cisco IOS XE-Prozesse nachverfolgt werden können.
Der Snapshot mit den maroon Statistiken enthält im Systembericht und hilft, einen potenziellen Schuldigen zu identifizieren, um den Speicherverbrauch zu ermitteln oder das Problem der RCA zu beheben oder es weiter zu debuggen und besser zu verstehen.
Anmerkung: Die Dekodierung des maroon stats-Verzeichnisses aus einem Systembericht kann nur vom TAC durchgeführt werden, da es interne und vertrauliche Funktionen von Code enthält, die dem TAC-Techniker helfen zu verstehen, welche Funktionen von Code den Speicher zuweisen. Bitte reichen Sie ein TAC-Ticket ein, und stellen Sie den Systembericht zur Verfügung.
Anmerkung: Beachten Sie, dass der Systembericht eine gute Datenmenge liefert, um einen Speicherabsturz aufgrund von Speichermangel zu verstehen. In einigen Fällen ist jedoch eine weitere Speicherüberwachung, Überwachung, Fehlerbehebung und Fehlerbehebung erforderlich.
Gerät ist noch nicht abgestürzt, aber es gibt Warnungen zur Speichernutzung
Der Befehl show platform resources zeigt Warnungen und kritische Schwellenwerte für die Speichernutzung an.
Hinweis: Es empfiehlt sich, speicherbezogene Ausgabebefehle zu sammeln, um weiter zu debuggen, da das Gerät, je nachdem, wie schnell der Speicherverbrauch oder das Speicherleck auftreten kann, aufgrund fehlender Speicherressourcen möglicherweise abstürzt.
Anmerkung: Wenn Warnungen zur Speichernutzung angezeigt werden, können Sie ein TAC-Ticket erstellen und Befehle eingeben, um den technischen Support und
zeigt einen Speicher des technischen Supports, der dem TAC-Techniker hilft, das Problem zu Beginn zu erkennen und möglicherweise eine RCA schnell zu finden.
Wenn das Gerät noch nicht abgestürzt ist und Speicherwarnungen im lokalen Syslog-Puffer generiert oder vom Syslog-Server über das Überwachungstool empfangen wird, sammeln Sie die Ausgabe der Speicherplattform show processes sortiert, um die Bytes zu ermitteln, die ggf. vom fehlerhaften Prozess verbraucht wurden.
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 dieser Ausgabe sehen Sie sich die Spalte Resident Set Size (RSS) an. Dieser Wert gibt an, wie viele Kilobyte die einzelnen Cisco IOS XE-Prozesse verbrauchen.
Identifizieren des Anrufstandorts
Als Nächstes sammeln Sie die Ausgabe von show-Prozessen Speicherplattform-Accounting, die die Diff-Aufrufe und Byte-Werte für verschiedene Prozesse zeigt. Normalerweise konzentrieren wir uns auf die größeren Werte.
Der Diff-Anruf Bytes ist ein guter Indikator, um festzustellen, ob es ein potenzielles Speicherleck geben kann, da er zeigt, wie viel Bytes Speicher noch vom System durch einen Prozess gehalten werden, ohne wieder an das System freigegeben zu werden.
Basierend auf diesen Daten können Sie identifizieren, welches der callsite-Tag des Angriffsprozesses ist, der die größeren Diff-Aufrufe und Byte-Werte hat.
Das show process memory platform accounting verfolgt diese Diff-Aufrufe und Bytes im Laufe der Zeit. In einigen Fällen befindet sich am unteren Rand dieser Befehlsausgabe ein Backtrace. Dies ist wichtig für den TAC-Techniker, da dieser Backtrace mit internen Tools decodiert wird und dazu beiträgt, zu bestimmen, welche Funktionen des Codes ein potenzielles Speicherleck verursachen können.
Anmerkung: Wenn der Befehl show process memory platform accounting nicht genügend Informationen bereitstellt, um ein Speicherleckproblem zu beheben, ist häufig ein weiteres Debuggen für einen Prozess erforderlich.
Siehe auch Debuggen der Callsite aus diesem Dokument für eine sekundäre Methode zum Identifizieren der Callsite.
Nutzung von Prozessspeicher in Modulen, Datenbanken und Messaging
Die Erfassung dieser Befehle für einen bestimmten Cisco IOS XE-Prozess kann erforderlich sein, um ein Cisco IOS XE-Prozess-Speicherleck weiter zu debuggen:
# 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_ Diese Befehlsausgaben ergänzen die Untersuchung eines durch einen Prozess verursachten Speicherverlusts und sind häufig erforderlich, wenn die ersten grundlegenden Triage-Befehle nicht genügend Informationen liefern.
Debuggen der Callsite
Eine sekundäre Methode zum Identifizieren der Aufrufsite besteht darin, sie zu debuggen. Diese Befehle sind erforderlich:
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 Der erste Befehl ermöglicht das Debuggen von Zuweisungen für die Aufrufsites eines Prozesses. In späteren Versionen ist dieser Befehl standardmäßig aktiviert und hat keine Auswirkungen auf den Dienst.
Der Befehl show platform software memory <process> <location> alloc callsite brief stellt eine Tabelle bereit, die die Aufrufsites für diesen Prozess sowie die Diff-Aufrufe und Bytes für jeden Aufrufstandort anzeigt. Hier zeigen wir beispielsweise die Ausgabe für den Cisco IOS-Prozess an, sie kann jedoch für jeden anderen Prozess erfasst werden:
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
Anmerkung: Der Befehl show plat soft memory <process> <location> alloc callsite bri muss mehrmals über die Zeit ausgeführt werden, bis festgestellt wird, dass der Diff-Aufruf oder die Byte-Spalte zunehmen, da dies ein Hinweis darauf wäre, dass das System diesen Speicher hält, ohne ihn freizugeben.
Sobald die als undicht erkannte Callsite undicht geworden ist, muss der Befehl debug platform software memory <process> <location> alloc backtrace start <callsite> depth 10 für diese Callsite ausgeführt werden. Dieser Befehl kann beibehalten werden und wirkt sich nicht auf den Service aus.
Wenn Sie den Befehl show plat soft memory <process> <location> alloc callsite bri erneut ausführen, bis nach dem Aktivieren des Debuggens der identifizierten Callsite immer noch Diff-Aufrufe/Byte-Erhöhungen erforderlich sind, um die Funktionen des Codes zu verfolgen, der Speicher für diese Callsite zuweist. Später kann die Rückverfolgung mithilfe von show platform software memory <process> <location> alloc backtrace erfasst werden, z. B.:
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: 70Anmerkung: Liefern Sie diese Ausgabe an das TAC zur Decodierung des Backtrace, dann kann der TAC-Techniker das Verhalten im Code überprüfen, feststellen, ob ein Fehler vorliegt, oder das Verhalten besser verstehen. Bei Bedarf kann das TAC das Entwicklerteam kontaktieren.
Hinweis: Stellen Sie sicher, dass die Software auf dem neuesten Stand ist. Sollte ein neuer Softwarefehler gefunden werden, kann TAC mit dem Entwicklerteam zusammenarbeiten, um den Zustand weiter zu debuggen und zu untersuchen.
Verwandte Artikel und Dokumentation
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
1.0 |
17-Oct-2025
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)