Probleme bei der Speichernutzung über EEM melden

Einleitung

In diesem Dokument werden allgemeine Tipps zur Fehlerbehebung beschrieben, wie Sie zusätzliche Informationen für ein Speicherverlustproblem sammeln können.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Grundkenntnisse in diesen Themen verfügen:

• Grundkenntnisse von Cisco IOS® XE
• Grundkenntnisse in Embedded Event Manager (EEM)

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt. Sie gilt für alle Cisco IOS XE Routing-Plattformen wie ASR1000, ISR4000, ISR1000, Cat8000 oder Cat8000v.

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

In diesem Dokument finden Sie allgemeine Protokolle, die das Gerät bei hoher Speichernutzung generiert.

Außerdem erfahren Sie, wie Sie von der Embedded Event Manager-Funktion profitieren können, die das TAC bei der Überwachung unterstützt und Daten zu Situationen abruft, in denen dem IOS XE-Router häufig der Arbeitsspeicher ausgeht.

In diesem Dokument werden Fehlerbehebungsverfahren nicht ausführlich erläutert, sofern verfügbar. Es werden lediglich Verweise auf ausführlichere Fehlerbehebungshandbücher bereitgestellt.

Symptome von IOS XE-Routern, denen der Arbeitsspeicher ausgeht

Bei Problemen mit hoher Speichernutzung wird in der Regel eine Protokollmeldung angezeigt, die darauf hinweist, dass die Warngrenze von 85 % erreicht wurde. Dieser Wert variiert je nach Version. Je nachdem, wo das System das Problem gefunden hat, werden unterschiedliche Protokolle generiert:

TCAM-Probleme:

CPP_FM-3-CPP_FM_TCAM_WARNUNG

IOSd (Kontrollebene):

SYS-2-MALLOCFAIL

SYS-2-CHUNKEXPANDFAIL

SYS-4-CHUNKSIBLINGSEXCEED

QFP (Datenebene):

QFPOOR-4-LOWRSRC_PERCENT_WARN

QFPOOR-4-TOP_EXMEM_USER

CPPEXMEM-3-NOMEM

CPPEXMEM-3-TOPUSER

Temporales Dateisystem (TMPFS):

PLATTFORM-3 - ELEMENT_TMPFS_WARNUNG

Allgemeines Systemprotokoll (Anforderungsisolierung):

PLATTFORM-4-ELEMENT_WARNUNG

PLATTFORM-3-ELEMENT_CRITICAL

Anmerkung: Protokollverbesserungen sind ab Version 16.12 verfügbar. 

Informationen, die das TAC für die erste Triage benötigt

• Ausgabe von Befehlen:

show clock

show version

Plattformressourcen anzeigen

show platform software status control-prozessor brief

Prozessspeicher sortiert anzeigen

Speicherstatistik anzeigen

Gesamtsummen des Arbeitsspeicherzuordnungsprozesses anzeigen

Prozessspeicherplattform sortiert anzeigen

show logging

• Bei unerwartetem Neuladen aufgrund eines schwachen Speichers:

Core-Datei/Systembericht

• Diagramm der Speichernutzung über die Zeit.

Das Hinzufügen eines Show-Technikers ist wünschenswert, hilfreich für das TAC, und Sie können von der Automatisierung profitieren, die das TAC entwickelt hat, damit Sie Probleme schneller finden.

Bedingungen, die zu einer hohen Speichernutzung führen, sind immer softwarebezogen. Nicht alle Fälle hoher Speichernutzung sind jedoch unerwartet. Es ist wichtig, die verfügbaren DRAMs und die auf dem Gerät ausgeführten Funktionen zu berücksichtigen.

Die Fehlerbehebung bei hoher Speichernutzung erfolgt mit Radkit reibungsloser, effektiver und mit besserer TAC-Interaktion. Dieses von Cisco entwickelte Tool bietet dem TAC eine hochsichere und einfache Möglichkeit, auf ausgewählte Geräte in Ihrem Netzwerk zuzugreifen. Weitere Informationen finden Sie unter: Cisco RADKit

Anmerkung: Stellen Sie sicher, dass eine unterstützte Version ausgeführt wird. Suchen Sie nach dem Dokument zum Ende des Vertriebszeitraums und zum Ende des Produktlebenszyklus für die Version. Wechseln Sie ggf. zu einer Version, die derzeit unter Softwarewartungsversionen läuft. Andernfalls kann das TAC auf die Fehlerbehebungs- und Lösungsoptionen beschränkt werden.

Ein vollständiges Dokument zur Speicherfehlerbehebung finden Sie in den folgenden Leitfäden:

Auf ISR4K: Handbuch zur Behebung von Speicherfehlern für Cisco ISR der Serie 4000.

Auf ASR1K: Fehlerbehebung beim Speicher des Routers der Serie ASR 1000

Informationen zur hohen Speichernutzung

Bei Cisco IOS XE-Routern ist DRAM eine der wichtigsten Ressourcen, die die Kernfunktionen unterstützt. DRAM wird zum Speichern verschiedener Datentypen und von Prozessen/Funktionen verwendet, die für den Betrieb auf Kontroll- und Datenebene erforderlich sind.

Die wichtigsten Einsatzbereiche von DRAM in IOS XE-Routern sind:

IOSd-Speicher (Kontrollebenenstrukturen): Speichert prozessbezogene Informationen zur Kontrollebene des Geräts, z. B.: Routinginformationen/-protokolle, Netzwerkverwaltungsstrukturen, Systemkonfigurationen und Funktionsinformationen.

QFP-Speicher (Datenebenenstrukturen): Speichert alle vom Mikrocode verarbeiteten QFP-Vorgänge, z. B. Schlüsselstrukturen der im QFP gespeicherten Funktionen, Mikrocodeanweisungen und Weiterleitungsanweisungen.

Temporary File System (TMPFS): TMPFS ist in DRAM installiert und wird von IOSd verwaltet und dient als schneller Speicherbereich für die Dateien, die von den Prozessen benötigt werden. Falls diese Dateien dauerhaft sind, werden sie auf eine Festplatte/einen Bootflash verschoben. Sie verbessert die Systemleistung, indem sie die Lese-/Schreibzeiten für temporäre Daten verkürzt.

Allgemeine Prozesse, die auf dem Linux-Kernel ausgeführt werden: Da IOS XE auf einem Linux-basierten Kernel arbeitet, unterstützt DRAM auch verschiedene Systemprozesse, die auf diesem Kernel laufen.

Eine hohe Speichernutzung von mehr als 85 % deutet in der Regel auf einen erheblichen DRAM-Verbrauch hin, der sich auf die Router-Leistung auswirken kann. Diese erhöhte Nutzung kann das Ergebnis legitimer Anforderungen wie der Speicherung umfangreicher Routing-Tabellen oder der Aktivierung ressourcenintensiver Funktionen sein. Es kann jedoch auch Probleme wie ineffizientes Speichermanagement durch bestimmte Funktionen oder Speicherlecks signalisieren, bei denen Speicher nach der Verwendung nicht ordnungsgemäß auf das System freigegeben wird.

Durch die Überwachung der Speichernutzung von IOSd-Speicher, QFP-Speicher, TMPFS und allgemeinen Linux-Prozessen können Sie und das TAC potenzielle Probleme frühzeitig erkennen.

EEM zur Überwachung der Speichernutzung

Zur Behebung von Speicherfehlern muss das TAC über einen bestimmten Zeitraum hinweg eine Reihe von Befehlen erfassen, um den jeweiligen Prozess zu identifizieren. In manchen Fällen, nachdem der verantwortliche Prozess identifiziert wurde, sind zusätzliche spezifische Befehle erforderlich, sodass die Behebung von Speicherfehlern zu den zeitaufwendigsten Arten der Fehlerbehebung gehört.

Um die Fehlerbehebung zu vereinfachen, können Sie die EEM-Funktion verwenden, um Informationen zu überwachen und automatisch zu sammeln. Beim Schreiben des EEM-Skripts müssen zwei Hauptaspekte beachtet werden: Trigger und zu erfassende Befehle.

Trigger

Muster. Sie können das Muster im Abschnitt Symptome von Cisco IOS XE-Routern verwenden, wenn nicht genügend Arbeitsspeicher vorhanden ist. Das Format sieht wie folgt aus:

event syslog pattern <pattern> ratelimit 300 max. 180

Eine der Überlegungen bei der Verwendung eines Musters als Auslöser besteht darin, dass das Protokoll generiert wird, sobald der Warnschwellenwert erreicht ist. Je nach Speicherverbrauch und manuellem Versuch haben Sie oder das TAC nicht genug Zeit für eine detailliertere Fehlerbehebung.

Cron-Timer. Beispiel für einen Cron-Timer, der alle 30 Minuten aktiviert wird:

Ereignis-Timer Cron-Name HalfHour Cron-Eintrag "*\30 * * * *"

Einer der Vorteile eines Cron-Timers gegenüber einem Muster besteht darin, dass Sie nicht warten müssen, bis das Gerät fast keine Speicherressourcen mehr hat, um Informationen zu sammeln. Abhängig von der Speicherbelegungsrate kann das TAC mit ordnungsgemäßer Überwachung und Informationen den fehlerhaften Prozess identifizieren, bevor es den Warnschwellenwert erreicht.

Anmerkung: Die Ratelimit- und Maxrun-Optionen garantieren, dass alle Ausgaben erfasst werden. Sie tragen außerdem dazu bei, zusätzliche Störungen oder eine EEM-Aktivierung zu vermeiden, wenn mehrere Protokolle innerhalb kurzer Zeit angezeigt werden.

EEM-Beispiele mit allgemeinen Befehlen für die erste Triage:

configure terminal
event manager applet TAC_EEM authorization bypass
event syslog pattern " PLATFORM-4-ELEMENT_WARNING" ratelimit 300 maxrun 180
action 0.1 cli command "enable"
action 0.2 cli command "term exec prompt timestamp"
action 0.3 cli command "term length 0"
action 0.4 cli command "show process memory platform sorted | append bootflash:TAC_EEM.txt"
action 0.5 cli command "show processes memory platform sorted location chassis 1 R0 | append bootflash:TAC_EEM.txt"
action 0.9 cli command "show platform resources | append bootflash:TAC_EEM.txt"
action 1.0 cli command "show platform software status control-processor brief | append bootflash:TAC_EEM.txt"
action 1.1 cli command "show clock | append bootflash:TAC_EEM.txt"
action 1.3 cli command "show platform software process memory chassis active r0 all sorted | append bootflash:TAC_EEM.txt"
action 1.5 cli command "show process memory platform accounting | append bootflash:TAC_EEM.txt"

Überwachung täglich mit einem Cron-Timer:

configure terminal
event manager applet TAC_EEM2 authorization bypass
event timer cron name DAYLY cron-entry "0 0 * * *"
action 0.1 cli command "enable"
action 0.2 cli command "term exec prompt timestamp"
action 0.3 cli command "term length 0"
action 0.4 cli command "show process memory platform sorted | append bootflash:TAC_EEM2.txt"
action 0.5 cli command "show processes memory platform sorted location chassis 1 R0 | append bootflash:TAC_EEM2.txt"
action 0.6 cli command "show processes memory platform sorted location chassis 2 R0 | append bootflash:TAC_EEM2.txt"
action 0.9 cli command "show platform resources | append bootflash:TAC_EEM2.txt"
action 1.0 cli command "show platform software status control-processor brief | append bootflash:TAC_EEM2.txt"
action 1.1 cli command "show log | append bootflash:TAC_EEM2.txt"
action 1.2 cli command "show clock | append bootflash:TAC_EEM2.txt"
action 1.3 cli command "show platform software process memory chassis active r0 all sorted | append bootflash:TAC_EEM2.txt"
action 1.5 cli command "show process memory platform accounting | append bootflash:TAC_EEM2.txt"

Eine umfassendere Liste der Befehle finden Sie in den Handbüchern im Abschnitt über die Anforderungen des TAC für die erste Triage.

Core-Datei

Wenn die Speichernutzung einen kritischen Wert erreicht, besteht die Wahrscheinlichkeit, dass das Betriebssystem einen Absturz erzwingt, um sich von diesem Zustand zu erholen, und einen Systembericht generiert, der eine Kerndatei enthält.

Die Core-Datei ist der vollständige Speicherauszug für einen bestimmten Prozess, der zu einem bestimmten Zeitpunkt abstürzt. Diese Core-Datei ist für das TAC von entscheidender Bedeutung, um den Speicher zu überprüfen und den Quellcode zu analysieren, um die Bedingungen und potenziellen Gründe für das unerwartete Neuladen/Abstürzen des Prozesses zu verstehen.

Die Kerndatei hilft TAC und Entwicklern, die Ursache des Problems zu finden, zu debuggen und das Problem zu beheben.

Anmerkung: Obwohl TAC und Entwickler danach streben, eine Ursache zu finden, gibt es Zeiten, in denen der Absturz eine Folge eines Netzwerkereignisses oder ein Zeitproblem war, das es praktisch unmöglich macht, ihn im Labor zu reproduzieren.

Weitere Informationen zu unerwarteten Neuladevorgängen und zum Abrufen einer Kerndatei finden Sie unter Problembehandlung bei unerwarteten Neuladevorgängen in Cisco IOS®-Plattformen mit TAC.