In diesem Dokument wird beschrieben, wie eine hohe CPU-Auslastung, die durch unterschiedliche Prozesse verursacht wird, behoben wird.
Wir empfehlen, dass Sie die Fehlerbehebung bei hoher CPU-Auslastung auf Cisco Routern lesen, bevor Sie mit diesem Dokument fortfahren.
Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.
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 sich Ihr Netzwerk in der Produktionsumgebung befindet, müssen Sie sich bei jedem Befehl zunächst dessen potenzielle Auswirkungen vor Augen führen.
Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).
Eine hohe CPU-Auslastung im ARP-Eingabeprozess (Address Resolution Protocol) tritt auf, wenn der Router eine übermäßige Anzahl von ARP-Anfragen generieren muss. Der Router verwendet ARP für alle Hosts, nicht nur für die Hosts im lokalen Subnetz, und ARP-Anfragen werden als Broadcasts gesendet, was zu einer höheren CPU-Auslastung auf jedem Host im Netzwerk führt. ARP-Anfragen für dieselbe IP-Adresse sind alle zwei Sekunden auf eine Anforderung beschränkt, sodass eine übermäßige Anzahl von ARP-Anfragen für verschiedene IP-Adressen generiert werden muss. Dies kann auftreten, wenn eine IP-Route konfiguriert wurde, die auf eine Broadcast-Schnittstelle verweist. Ein offensichtliches Beispiel ist eine Standardroute wie:
ip route 0.0.0.0 0.0.0.0 Fastethernet0/0
In diesem Fall generiert der Router eine ARP-Anfrage für jede IP-Adresse, die nicht über spezifischere Routen erreichbar ist. Dies bedeutet praktisch, dass der Router eine ARP-Anfrage für fast jede Adresse im Internet generiert. Weitere Informationen zum Konfigurieren der nächsten Hop-Adresse für statisches Routing finden Sie unter Angeben einer Next-Hop-IP-Adresse für statische Routen.
Alternativ kann eine übermäßige Anzahl von ARP-Anfragen durch einen schädlichen Datenverkehrsstrom verursacht werden, der über lokal angeschlossene Subnetze scannt. Ein Hinweis auf einen solchen Stream wäre die sehr hohe Anzahl unvollständiger ARP-Einträge in der ARP-Tabelle. Da eingehende IP-Pakete, die ARP-Anfragen auslösen würden, verarbeitet werden müssen, entspricht die Problembehebung im Wesentlichen der Behebung einer hohen CPU-Auslastung im IP Input-Prozess.
Der IPX-Eingabeprozess ähnelt dem IP-Eingabe-Prozess, da er das Switching von Prozessen übernimmt, mit der Ausnahme, dass der IPX-Eingabeprozess IPX-Pakete schaltet. Fast alle IPX-Pakete werden auf Prozessebene von IPX Input geprüft, bevor sie in die Warteschlange für andere IPX-Prozesse wie IPX SAP In, IPX RIP In usw. gestellt werden. Im Gegensatz zu IP unterstützt IPX nur einen Interrupt-Switching-Modus, d. h. IPX Fast-Switching, der standardmäßig aktiviert ist. IPX Fast Switching wird mit dem Schnittstellenbefehl ipx route-cache aktiviert.
Wenn während des IPX-Eingangsprozesses eine hohe CPU-Auslastung festgestellt wird, überprüfen Sie Folgendes:
IPX Fast-Switching ist deaktiviert. Wenn das IPX Fast Switching deaktiviert ist, verwenden Sie den Befehl show ipx interface.
Ein Teil des IPX-Datenverkehrs kann nicht über IPX Fast Switched erfolgen:
IPX-Broadcasts - Überprüfen Sie, ob der Router mit IPX-Broadcasts überlastet ist. Verwenden Sie dazu den Befehl show ipx traffic.
IPX-Routing-Updates - Bei zahlreichen Instabilitäten im Netzwerk nimmt die Verarbeitung von Routing-Updates zu.
Hinweis: Verwenden Sie anstelle von IPX RIP IPX EIGRP (inkrementell), um die Anzahl der Updates zu reduzieren, insbesondere über serielle Verbindungen mit langsamer Geschwindigkeit (weitere Informationen finden Sie unter Routing von Novell IPX über langsame serielle Leitungen und SAP-Management).
Hinweis: Weitere Dokumente zu IPX-Technologien finden Sie auf der Support-Seite für die Novell IPX-Technologie.
Wenn der Transmission Control Protocol (TCP)-Timer-Prozess eine Menge CPU-Ressourcen verwendet, deutet dies darauf hin, dass zu viele TCP-Verbindungsendpunkte vorhanden sind. Dies kann in DLSw-Umgebungen (Data Link Switching) mit vielen Peers oder in anderen Umgebungen geschehen, in denen viele TCP-Sitzungen gleichzeitig auf dem Router geöffnet werden.
Der FIB-Steuerungs-Timer initialisiert und startet den FIB Statistics Collection-Timer für VLAN-Statistiken und globale Statistiken. Initialisiert und startet den FIB/ADJ-Anforderungs-/Ausnahmeherstellungs-Timer; verwaltet die FIB-bezogenen Registrierungsfunktionen; und initialisiert den BGP Accounting Timer. Diese Prozesse werden gestartet, wenn EARL initialisiert wird.
Der TTY Background-Prozess ist ein generischer Prozess, der von allen Terminalleitungen (Konsole, aux, async usw.) verwendet wird. In der Regel sollte die Leistung des Routers nicht beeinträchtigt werden, da dieser Prozess eine geringere Priorität hat als die anderen Prozesse, die von der Cisco IOS-Software geplant werden müssen.
Wenn dieser Vorgang eine hohe CPU-Auslastung erfordert, prüfen Sie, ob "logging synchronous" unter "line con 0" konfiguriert ist. Mögliche Ursache ist die Cisco Bug ID CSCed16920 (nur registrierte Kunden) Cisco Bug ID oder CSCdy01705 (nur registrierte Kunden).
Die für den "TAG Stats Background"-Prozess ermittelte CPU-Auslastung wird erwartet und beeinflusst die Weiterleitung des Datenverkehrs nicht.
Der TAG-Statistikhintergrund ist ein Prozess mit niedriger Priorität. Dieser Prozess erfasst Statistiken für Tags und leitet sie an den RP weiter. Dies hängt nicht vom Datenverkehrsaufkommen ab, sondern von der Arbeit, die die MPLS-/LDP-Kontrollebene leistet. Dies ist ein erwartetes Verhalten, das sich nicht auf die Weiterleitung des Datenverkehrs auswirkt. Dieses Problem ist im Bug CSCdz32988 dokumentiert (nur registrierte Kunden) .
Für jede neue virtuelle Zugriffsschnittstelle muss eine virtuelle Vorlage (Vorlage) geklont werden, wenn ein neuer Benutzer mit dem Router oder dem Zugriffsserver verbunden wird. Die CPU-Auslastung im vTemplate Backgr-Prozess kann extrem hoch sein, wenn die Anzahl der Benutzer groß ist. Dies kann durch die Konfiguration des Vorklonens der virtuellen Vorlage vermieden werden. Weitere Informationen finden Sie unter Erweiterungen der Sitzungsskalierbarkeit.
Der Net Background-Prozess wird immer ausgeführt, wenn ein Puffer erforderlich ist, aber für den Prozess oder die Schnittstelle nicht verfügbar ist. Auf Anfrage werden die gewünschten Puffer aus dem Hauptpool erstellt. Net background verwaltet auch den von jedem Prozess verwendeten Speicher und räumt den freigegebenen Speicher. Dieser Prozess ist hauptsächlich mit den Schnittstellen verknüpft und kann erhebliche CPU-Ressourcen beanspruchen. Die Symptome einer hohen CPU sind eine Zunahme der Kehle, Ignorieren, Überläufe und Zurücksetzen auf einer Schnittstelle.
Der IP Background-Prozess umfasst folgende Verfahren: die periodische Alterung des ICMP-Redirect-Cache jede Minute; eine Änderung des Kapselungstyps einer Schnittstelle; die Verschiebung einer Schnittstelle in einen neuen Zustand, UP und/oder DOWN; eine Änderung der IP-Adresse der Schnittstelle; Ablauf einer neuen dxi-Karte; und der Ablauf von Dialer-Timern.
Der IP Background-Prozess ändert die Routing-Tabelle entsprechend dem Status der Schnittstellen, während beim IP Background-Prozess davon ausgegangen wird, dass beim Empfang von Link-State-Änderungsnachrichten eine Änderung des Verbindungsstatus vorliegt. Anschließend werden alle Routing-Protokolle benachrichtigt, um die betroffene Schnittstelle zu überprüfen. Wenn auf mehr Schnittstellen Routing-Protokolle ausgeführt werden, wird eine höhere CPU-Auslastung durch den IP Background-Prozess verursacht.
ARP-Hintergrundprozesse verarbeiten mehrere Jobs und können eine hohe CPU-Auslastung verbrauchen.
Diese Liste enthält einige Beispielaufträge:
ARP-Flush aufgrund von Schnittstellenaktivierungs-/-down-Ereignissen
Löschen der ARP-Tabelle mithilfe des Befehls clear arp
ARP-Eingabepakete
ARP-Manager
Wenn ein anderer Prozess eine Menge CPU-Ressourcen beansprucht und keine Hinweise auf ein Problem in den protokollierten Nachrichten vorhanden sind, kann das Problem möglicherweise durch einen Fehler in der Cisco IOS®-Software verursacht werden. Führen Sie mithilfe des Bug Toolkit (nur registrierte Kunden) eine Suche nach dem angegebenen Prozess durch, um festzustellen, ob Fehler gemeldet wurden.
Wenn Sie nach den oben beschriebenen Schritten zur Fehlerbehebung weiterhin Hilfe benötigen und eine Serviceanfrage beim Cisco TAC erstellen möchten, geben Sie folgende Informationen an: |
---|
|
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
1.0 |
29-Sep-2008 |
Erstveröffentlichung |