Inhalt

Einleitung

Voraussetzungen

Verwendete Komponenten

Hintergrundinformationen

Was ist die Callsite?

Diff-Anrufe und Diff-Bytes

Symptome bei Speicherverbrauch oder Leckproblemen

Fehlerbehebungsszenarien

Das Gerät ist aufgrund von zu wenig Speicher abgestürzt.

Gerät ist noch nicht abgestürzt, aber es gibt Warnungen zur Speichernutzung

Identifizieren des Anrufstandorts

Nutzung von Prozessspeicher in Modulen, Datenbanken und Messaging

Debuggen der Callsite

Verwandte Artikel und Dokumentation

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

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

- Fehlerbehebung: ASR 1000 Router-Speicher

- Prüfung der IOS-XE-Speichernutzung

- Probleme bei der Speichernutzung über EEM melden

- Anleitung zur Fehlerbehebung bei Cisco ISR der Serie 4000