WAAS - Optimierung der Fehlerbehebung
Kapitel: Optimierung der Fehlerbehebung
In diesem Artikel wird die Fehlerbehebung bei der grundlegenden Optimierung beschrieben.
Hauptartikel
Analyse der WAAS-Architektur und des Datenverkehrsflusses
Vorläufige WAAS-Fehlerbehebung
Optimierung der Fehlerbehebung
Problembehebung Anwendungsbeschleunigung
Fehlerbehebung CIFS AO
Fehlerbehebung für HTTP AO
Fehlerbehebung für EPM AO
Fehlerbehebung bei MAPI AO
Fehlerbehebung: NFS AO
Fehlerbehebung bei SSL AO
Fehlerbehebung bei Video-Audio
Fehlerbehebung bei generischem AO
Fehlerbehebung bei Überlastungsbedingungen
Fehlerbehebung WCCP
Fehlerbehebung AppNav
Fehlerbehebung bei Festplatten- und Hardwareproblemen
Fehlerbehebung bei seriellen Inline-Clustern
vWAAS-Fehlerbehebung
Fehlerbehebung: WAAS Express
Fehlerbehebung NAM-Integration
Inhalt
Die grundlegenden WAAS-Optimierungen umfassen TCP Flow Optimization (TFO), Data Redundancy Elimination (DRE) und die dauerhafte Lempel-Ziv-Komprimierung (LZ).
TFO-Fehlerbehebung
Die Anzahl der TCP-Verbindungen, ihr Status und ihre Einstufung können einen Hinweis auf den Zustand des WAAS-Systems an einem bestimmten Standort geben. Ein gesundes System zeigt eine große Anzahl von Verbindungen an, von denen ein beträchtlicher Teil normal geschlossen ist. Der Befehl show statistics (show statistics to detail) gibt an, wie groß die Anzahl, der Status und der Status der Verbindungen zwischen einem bestimmten WAAS-Gerät und anderen Geräten im Netzwerk sind.
Sie können globale TFO-Statistiken anzeigen, indem Sie den Befehl show statistics tfdetail wie folgt verwenden:
WAE# show statistics tfo detail
Total number of connections : 2852
No. of active connections : 3 <-----Active connections
No. of pending (to be accepted) connections : 0
No. of bypass connections : 711
No. of normal closed conns : 2702
No. of reset connections : 147
Socket write failure : 0
Socket read failure : 0
WAN socket close while waiting to write : 0
AO socket close while waiting to write : 2
WAN socket error close while waiting to read : 0
AO socket error close while waiting to read : 64
DRE decode failure : 0
DRE encode failure : 0
Connection init failure : 0
WAN socket unexpected close while waiting to read : 32
Exceeded maximum number of supported connections : 0
Buffer allocation or manipulation failed : 0
Peer received reset from end host : 49
DRE connection state out of sync : 0
Memory allocation failed for buffer heads : 0
Unoptimized packet received on optimized side : 0
Data buffer usages:
Used size: 0 B, B-size: 0 B, B-num: 0
Cloned size: 0 B, B-size: 0 B, B-num: 0
Buffer Control:
Encode size: 0 B, slow: 0, stop: 0
Decode size: 0 B, slow: 0, stop: 0
Scheduler:
Queue Size: IO: 0, Semi-IO: 0, Non-IO: 0
Total Jobs: IO: 1151608, Semi-IO: 5511278, Non-IO: 3690931
Policy Engine Statistics
-------------------------
Session timeouts: 0, Total timeouts: 0
Last keepalive received 00.5 Secs ago
Last registration occurred 15:00:17:46.0 Days:Hours:Mins:Secs ago
Hits: 7766, Update Released: 1088
Active Connections: 3, Completed Connections: 7183
Drops: 0
Rejected Connection Counts Due To: (Total: 0)
Not Registered : 0, Keepalive Timeout : 0
No License : 0, Load Level : 0
Connection Limit : 0, Rate Limit : 0 <-----Connection limit overload
Minimum TFO : 0, Resource Manager : 0
Global Config : 0, TFO Overload : 0
Server-Side : 0, DM Deny : 0
No DM Accept : 0
. . .
Das Feld Anzahl der aktiven Verbindungen gibt die Anzahl der Verbindungen an, die derzeit optimiert werden.
Im Abschnitt "Policy Engine Statistics" der Ausgabe werden im Abschnitt "Rejected Connection Counts" (Anzahl abgelehnter Verbindungen) verschiedene Gründe für die Ablehnung von Verbindungen angezeigt. Der Zähler Connection Limit (Verbindungsgrenze) meldet die Anzahl der abgelehnten Verbindungen, da die maximale Anzahl optimierter Verbindungen überschritten wurde. Wenn Sie hier eine hohe Anzahl sehen, sollten Sie sich die Überlastungsbedingungen ansehen. Weitere Informationen finden Sie im Artikel Fehlerbehebung bei Überlastungsbedingungen.
Darüber hinaus wird die TFO-Optimierung für Verbindungen, die von anderen AOs heruntergefahren werden, da sie den Datenverkehr nicht optimieren können, von der generischen AO übernommen, die im Artikel Problembehandlung bei generischen AO behandelt wird.
Sie können TFO-Verbindungsstatistiken anzeigen, indem Sie den Befehl show statistics connection verwenden. Weitere Informationen zur Verwendung dieses Befehls finden Sie im Abschnitt "Überprüfen der optimierten TCP-Verbindungen" im Artikel Troubleshooting Overload Conditions (Bedingungen für die Fehlerbehebung bei Überlastung).
DRE-Fehlerbehebung
Wenn eine Anwendungsbeschleunigung erwartet, aber nicht beobachtet wird, stellen Sie sicher, dass die entsprechenden Optimierungen auf den Datenverkehrsfluss angewendet werden und dass der DRE-Cache die Größe des optimierten Datenverkehrs entsprechend reduziert.
Die Richtlinien-Engine-Karten für die DRE- und LZ-Optimierung umfassen folgende Punkte:
- DRE + LZ (voll): Policy-Engine-Anwendungszuordnung andere optimieren vollständige
- Nur DRE: Richtlinienbasierte Anwendungszuordnung optimiert DRE ja Komprimierung keine
- Nur LZ: Policy-Engine-Anwendungszuordnung andere optimieren DRE ohne Komprimierung LZ
- TFO-Passthrough: Policy-Engine-Anwendungs-Map anderer Passthrough
Verschiedene Bedingungen können dazu führen, dass DRE und/oder LZ nicht auf eine Verbindung angewendet werden, auch wenn diese konfiguriert ist:
- Cache-Initialisierung wird ausgeführt
- Festplatten-E/A-Fehler
- Geringer Speicher
- Daten können nicht komprimiert werden, oder der Gewinn ist zu gering.
- Daten werden so verschlüsselt, dass sie keine wiederholten Bytefolgen enthalten
- Nachrichten sind zu klein, um von der Komprimierung zu profitieren
Hinweis: Unter allen oben genannten Bedingungen meldet der Befehl show statistics connection die Beschleunigung von "TDL" für Verbindungen, bei denen dies die ausgehandelte Richtlinie war. Wenn Sie die Menge des DRE- oder LZ-Bypassdatenverkehrs betrachten, wird Ihnen mitgeteilt, ob die DRE- oder LZ-Optimierungen tatsächlich angewendet wurden. Verwenden Sie den Befehl show statistics connection conn-id (wie weiter unten beschrieben), und überprüfen Sie die DRE-Codenummern, ob das Verhältnis DRE oder LZ bei 0 % liegt und der Großteil des Datenverkehrs umgangen wird. Die ersten drei Bedingungen werden im Feld "Encode Bypass due to" (Umgehung von Code aufgrund) gemeldet, und die letzten drei Bedingungen ergeben sich aus dem Datenverkehrsmuster und werden in den gemeldeten DRE- und LZ-Verhältnissen berücksichtigt.
Sie können die Statistiken für eine bestimmte Verbindung anzeigen, um zu bestimmen, welche grundlegenden Optimierungen konfiguriert, mit dem Peer ausgehandelt und mithilfe des Befehls show statistics connection conn-id angewendet wurden. Zuerst müssen Sie die Verbindungs-ID für eine bestimmte Verbindung mithilfe des Befehls show statistics connection ermitteln:
WAE#show stat conn Current Active Optimized Flows: 1 Current Active Optimized TCP Plus Flows: 0 Current Active Optimized TCP Only Flows: 1 Current Active Optimized TCP Preposition Flows: 0 Current Active Auto-Discovery Flows: 0 Current Reserved Flows: 10 Current Active Pass-Through Flows: 0 Historical Flows: 375 D:DRE,L:LZ,T:TCP Optimization RR:Total Reduction Ratio A:AOIM,C:CIFS,E:EPM,G:GENERIC,H:HTTP,M:MAPI,N:NFS,S:SSL,V:VIDEO ConnID Source IP:Port Dest IP:Port PeerID Accel RR 343 10.10.10.10:3300 10.10.100.100:80 00:14:5e:84:24:5f T 00.0% <------
Sie finden die Verbindungs-IDs für die einzelnen Verbindungen am Ende der Ausgabe. Um die Statistiken für eine bestimmte Verbindung anzuzeigen, verwenden Sie den Befehl show statistics connection conn-id wie folgt:
WAE# sh stat connection conn-id 343
Connection Id: 343
Peer Id: 00:14:5e:84:24:5f
Connection Type: EXTERNAL CLIENT
Start Time: Tue Jul 14 16:00:30 2009
Source IP Address: 10.10.10.10
Source Port Number: 3300
Destination IP Address: 10.10.100.100
Destination Port Number: 80
Application Name: Web <-----Application name
Classifier Name: HTTP <-----Classifier name
Map Name: basic
Directed Mode: FALSE
Preposition Flow: FALSE
Policy Details:
Configured: TCP_OPTIMIZE + DRE + LZ <-----Configured policy
Derived: TCP_OPTIMIZE + DRE + LZ
Peer: TCP_OPTIMIZE + DRE + LZ
Negotiated: TCP_OPTIMIZE + DRE + LZ <-----Policy negotiated with peer
Applied: TCP_OPTIMIZE + DRE + LZ <-----Applied policy
. . .
In den Feldern Application Name (Anwendungsname) und Classifier Name (Klassifizierungsname) werden die auf diese Verbindung angewendete Anwendung und Klassifizierung angezeigt.
Die Optimierungsrichtlinien werden im Abschnitt "Richtliniendetails" aufgeführt. Wenn die konfigurierten und die angewendeten Richtlinien nicht übereinstimmen, bedeutet dies, dass Sie für diesen Verbindungstyp eine Richtlinie konfiguriert haben, aber eine andere Richtlinie angewendet wurde. Dies kann darauf zurückzuführen sein, dass der Peer ausgefallen, falsch konfiguriert oder überladen ist. Überprüfen Sie die Peer-WAE und deren Konfiguration.
Im folgenden Ausgabesegment werden Statistiken zu DRE-Codes bzw. -Decodierungen aufgeführt, darunter die Anzahl der Meldungen, die Anzahl der angewendeten DRE, die LZ-Anwendung oder die Umgehung von DRE und LZ:
. . .
DRE: 353
Conn-ID: 353 10.10.10.10:3304 -- 10.10.100.100:139 Peer No: 0 Status: Active
------------------------------------------------------------------------------
Open at 07/14/2009 16:04:30, Still active
Encode:
Overall: msg: 178, in: 36520 B, out: 8142 B, ratio: 77.71% <-----Overall compression
DRE: msg: 1, in: 356 B, out: 379 B, ratio: 0.00% <-----DRE compression ratio
DRE Bypass: msg: 178, in: 36164 B <-----DRE bypass
LZ: msg: 178, in: 37869 B, out: 8142 B, ratio: 78.50% <-----LZ compression ratio
LZ Bypass: msg: 0, in: 0 B <-----LZ bypass
Avg latency: 0.335 ms Delayed msg: 0 <-----Avg latency
Encode th-put: 598 KB/s <-----In 4.3.3 and earlier only
Message size distribution:
0-1K=0% 1K-5K=0% 5K-15K=0% 15K-25K=0% 25K-40K=0% >40K=0% <-----In 4.3.3 and earlier only
Decode:
Overall: msg: 14448, in: 5511 KB, out: 420 MB, ratio: 98.72% <-----Overall compression
DRE: msg: 14372, in: 5344 KB, out: 419 MB, ratio: 98.76% <-----DRE compression ratio
DRE Bypass: msg: 14548, in: 882 KB <-----DRE bypass
LZ: msg: 14369, in: 4891 KB, out: 5691 KB, ratio: 14.07% <-----LZ compression ratio
LZ Bypass: msg: 79, in: 620 KB <-----LZ bypass
Avg latency: 4.291 ms <-----Avg latency
Decode th-put: 6946 KB/s <-----In 4.3.3 and earlier only
Message size distribution:
0-1K=4% 1K-5K=12% 5K-15K=18% 15K-25K=9% 25K-40K=13% >40K=40% <-----Output from here in 4.3.3 and earlier only
. . .
Im obigen Beispiel werden die folgenden Statistiken sowohl für die Kodierung als auch für die Decodierung hervorgehoben:
- Gesamtverhältnis - das Gesamtkomprimierungsverhältnis für Daten, einschließlich DRE und LZ
- DRE Ratio - das Komprimierungsverhältnis aufgrund von DRE alleine
- DRE-Umgehung - Die Anzahl der Nachrichten und Byte, die DRE umgangen haben
- LZ Ratio - das Komprimierungsverhältnis aufgrund der LZ alleine
- LZ Bypass: Die Anzahl der Nachrichten und Byte, die LZ umgangen haben
- Durchschnittliche Latenz - die durchschnittliche Latenz für den Code- oder Decodierungsvorgang.
Wenn ein großer Teil des Umgehungsdatenverkehrs angezeigt wird, ist die DRE-Komprimierungsrate geringer als erwartet. Dies kann auf verschlüsselten Datenverkehr, kleine Nachrichten oder auf andere Weise unkomprimierbare Daten zurückzuführen sein. Kontaktieren Sie das TAC, um weitere Hilfe bei der Fehlerbehebung zu erhalten.
Wenn Sie eine große Menge an LZ Bypass-Datenverkehr sehen, kann dies auf einen hohen Anteil an verschlüsseltem Datenverkehr zurückzuführen sein, der im Allgemeinen nicht komprimierbar ist.
Die Durchschnittliche Latenz kann beim Debuggen eines Durchsatzproblems hilfreich sein. Je nach Plattform liegt die durchschnittliche Latenz sowohl bei der Codierung als auch bei der Dekodierung in der Regel im einstelligen ms. Wenn Benutzer einen niedrigen Durchsatz erzielen und eine oder beide Zahlen höher sind, weist dies auf ein Problem bei der Kodierung oder Decodierung hin, das in der Regel neben der höheren Latenz liegt.
Es kann hilfreich sein, die DRE-Statistikdaten wie die ältesten verwendbaren Daten, die Cachegröße, den Prozentsatz des verwendeten Cache, den verwendeten Hashtable-RAM usw. mithilfe des Befehls show statistics dre detail wie folgt zu betrachten:
WAE# sh stat dre detail
Cache:
Status: Usable, Oldest Data (age): 10h <-----Cache age
Total usable disk size: 311295 MB, Used: 0.32% <-----Percent cache used
Hash table RAM size: 1204 MB, Used: 0.00% <-----Output from here is in 4.3.3 and earlier only
. . .
Wenn Sie keine nennenswerte DRE-Komprimierung sehen, könnte dies daran liegen, dass der DRE-Cache nicht mit genügend Daten gefüllt ist. Überprüfen Sie, ob das Cache-Alter kurz ist und weniger als 100 Prozent des Cache verwendet wird. Dies würde auf diese Situation hinweisen. Das Komprimierungsverhältnis sollte sich verbessern, wenn der Cache mehr Daten enthält. Wenn 100 % des Cache verwendet werden und das Cache-Alter kurz ist, weist dies darauf hin, dass die WAE möglicherweise zu klein ist und das Datenverkehrsvolumen nicht verarbeiten kann.
Wenn Sie keine nennenswerte DRE-Komprimierung sehen, sehen Sie sich die Nack/R-tx-Zähler im folgenden Abschnitt der Befehlsausgabe an:
Connection details:
Chunks: encoded 398832, decoded 269475, anchor(forced) 43917(9407) <-----In 4.3.3 and earlier only
Total number of processed messges: 28229 <-----In 4.3.3 and earlier only
num_used_block per msg: 0.053597 <-----In 4.3.3 and earlier only
Ack: msg 18088, size 92509 B <-----In 4.3.3 and earlier only
Encode bypass due to: <-----Encode bypass reasons
remote cache initialization: messages: 1, size: 120 B
last partial chunk: chunks: 482, size: 97011 B
skipped frame header: messages: 5692, size: 703 KB
Nacks: total 0 <-----Nacks
R-tx: total 0 <-----Retransmits
Encode LZ latency: 0.133 ms per msg
Decode LZ latency: 0.096 ms per msg
. . .
Die Nacks und R-tx-Zähler sollten im Allgemeinen im Verhältnis zum Datenverkehrsvolumen niedrig sein. Beispielsweise liegt der ursprüngliche (nicht optimierte) Datenverkehr bei etwa 1 pro 100 MB. Wenn die Anzahl deutlich höher ist, kann dies auf ein Problem bei der Synchronisierung des DRE-Caches hinweisen. Verwenden Sie den Befehl clear cache dre, um den DRE-Cache auf allen Geräten zu löschen, oder wenden Sie sich an das TAC.
Die Zähler für die Umgehungsgründe für den Code geben aus verschiedenen Gründen die Anzahl der umgeleiteten Bytes an. Dies kann Ihnen helfen zu bestimmen, was Umgehungsdatenverkehr verursacht (außer einem nicht optimierbaren Datenmuster).
Manchmal ist es hilfreich, die angeschlossenen und aktiven Peer-WAEs zu identifizieren und Peer-Statistiken anzuzeigen. Dies können Sie mit dem Befehl show statistics peer (Statistiken anzeigen) wie folgt tun:
WAE# sh stat peer dre
Current number of connected peers: 1
Current number of active peers: 1
Current number of degrade peers: 0
Maximum number of connected peers: 1
Maximum number of active peers: 1
Maximum number of degraded peers: 0
Active peer details:
Peer-No : 0 Context: 65027
Peer-ID : 00:14:5e:95:4a:b5
Hostname: wae7.example.com <-----Peer hostname
------------------------------------------------------------------------------
Cache: Used disk: 544 MB, Age: 14d23h <-----Peer cache details in 4.3.3 and earlier only
Cache: Used disk: 544 MB <-----Peer cache details in 4.4.1 and later only
Peer version: 0.4 <-----
Ack-queue size: 38867 KB |
Buffer surge control: |<---In 4.3.3 and earlier only
Delay: avg-size 0 B, conn: 0, flush: 0 |
Agg-ft: avg-size 20902 B, conn: 388, flush: 0 |
remote low-buff: 0, received flush: 0 <-----
Connections: Total (cumulative): 3226861, Active: 597
Concurrent Connections (Last 2 min): max 593, avg 575
. . .
Die andere Ausgabe dieses Befehls zeigt die Statistiken zum Codieren und Decodieren ähnlich einer einzelnen Verbindung an.
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)