In questo articolo viene descritto come risolvere i problemi relativi all'ottimizzazione di base.
Le ottimizzazioni WAAS di base includono l'ottimizzazione del flusso TCP (TFO), l'eliminazione della ridondanza dei dati (DRE) e la compressione Lempel-Ziv (LZ) persistente.
Il numero di connessioni TCP, il loro stato e la loro disposizione possono fornire un'indicazione dello stato del sistema WAAS in una posizione specifica. Un sistema integro mostra un gran numero di connessioni, con una percentuale significativamente alta di queste chiuse normalmente. Il comando show statistics for detail fornisce un'indicazione del volume, dello stato e della disposizione delle connessioni tra una particolare periferica WAAS e altre periferiche nella rete.
È possibile visualizzare le statistiche TFO globali utilizzando il comando show statistics tfo detail come indicato di seguito:
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
. . .
Il campo N. di connessioni attive indica il numero di connessioni attualmente in fase di ottimizzazione.
Nella sezione Statistiche motore dei criteri dell'output, la sezione Conteggi connessioni rifiutate mostra vari motivi per cui le connessioni sono state rifiutate. Il contatore Limite connessioni indica quante volte una connessione è stata rifiutata a causa del superamento del numero massimo di connessioni ottimizzate. Se vedete un numero alto qui, dovreste esaminare le condizioni di sovraccarico. Per ulteriori informazioni, vedere l'articolo Risoluzione dei problemi relativi alle condizioni di sovraccarico.
Inoltre, l'ottimizzazione TFO per le connessioni che vengono disattivate da altri oggetti attivazione in quanto non possono ottimizzare il traffico viene gestita dall'oggetto attivazione generico, descritto nell'articolo Risoluzione dei problemi dell'oggetto attivazione generico.
È possibile visualizzare le statistiche di connessione TFO utilizzando il comando show statistics connection. Per i dettagli sull'utilizzo di questo comando, vedere la sezione "Checking the Optimized TCP Connections" nell'articolo Troubleshooting Overload Conditions.
Se l'accelerazione dell'applicazione è prevista ma non è osservata, verificare che le ottimizzazioni appropriate siano applicate al flusso di traffico e che la cache DRE stia riducendo in modo appropriato le dimensioni del traffico ottimizzato.
Le mappe del motore delle regole per l'ottimizzazione di DRE e LZ includono:
A causa di diverse condizioni, non è possibile applicare DRE e/o LZ a una connessione, anche se è configurata:
Nota: In tutte le condizioni precedenti, il comando show statistics connection segnalerà l'accelerazione di "TDL" per le connessioni in cui questo era il criterio negoziato. Se si osserva la quantità di traffico di bypass DRE o LZ, verrà indicato se le ottimizzazioni DRE o LZ sono state effettivamente applicate. Utilizzare il comando show statistics connection conn-id, come descritto più avanti, e controllare i numeri di codifica DRE per verificare se il rapporto DRE o LZ è vicino allo 0% e se la maggior parte del traffico viene ignorata. Le prime tre condizioni sono segnalate nel campo "Codifica bypass a causa di" e le ultime tre risultano dallo schema dei dati sul traffico e sono considerate nei rapporti DRE e LZ segnalati.
È possibile visualizzare le statistiche per una connessione specifica per determinare quali ottimizzazioni di base sono state configurate, negoziate con il peer e applicate utilizzando il comando show statistics connection conn-id. È necessario innanzitutto determinare l'ID connessione per una connessione specifica utilizzando il comando show statistics connection, come indicato di seguito:
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% <------
Gli ID di connessione per ciascuna connessione sono elencati alla fine dell'output. Per visualizzare le statistiche per una connessione specifica, utilizzare il comando show statistics connection conn-id, come indicato di seguito:
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
. . .
I campi Nome applicazione e Nome classificatore indicano l'applicazione e il classificatore applicati alla connessione.
I criteri di ottimizzazione sono elencati nella sezione Dettagli criteri. Se i criteri Configurato e Applicato non corrispondono, significa che è stato configurato un criterio per questo tipo di connessione, ma è stato applicato un criterio diverso. Ciò può verificarsi in caso di inattività, configurazione errata o sovraccarico del peer. Controllare WAE peer e la relativa configurazione.
Nella sezione di output riportata di seguito vengono mostrate le statistiche relative alla codifica/decodifica DRE, inclusi il numero di messaggi, il numero di messaggi a cui è stato applicato DRE, LZ applicato o ignorato DRE e 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
. . .
Nell'esempio precedente sono evidenziate le seguenti statistiche sia per la codifica che per la decodifica:
Se si rileva una grande quantità di traffico di bypass, il rapporto di compressione DRE sarà inferiore al previsto. La causa potrebbe essere traffico crittografato, messaggi di piccole dimensioni o dati non compressibili. Per ulteriori informazioni sulla risoluzione dei problemi, contattare TAC.
Se si rileva una grande quantità di traffico LZ Bypass, ciò potrebbe essere dovuto a una grande quantità di traffico crittografato, che in genere non è comprimibile.
I numeri di latenza media possono essere utili per il debug di un problema di velocità effettiva. A seconda della piattaforma, la latenza media di codifica e decodifica è in genere espressa con una sola cifra di ms. Se il throughput è basso e uno o entrambi questi numeri sono più alti, si verifica un problema di codifica o decodifica, generalmente sul lato con la latenza più alta.
Può essere utile esaminare i dati delle statistiche DRE, ad esempio i dati più vecchi utilizzabili, le dimensioni della cache, la percentuale di cache utilizzata, la RAM della tabella hash utilizzata e così via, utilizzando il comando show statistics dre detail, come indicato di seguito:
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
. . .
Se la compressione DRE non è significativa, è possibile che la cache DRE non sia popolata con dati sufficienti. Verificare se la durata della cache è breve e se viene utilizzato meno del 100% della cache, il che indica questa situazione. Il rapporto di compressione dovrebbe migliorare man mano che la cache si riempie di dati. Se si utilizza il 100% della cache e la durata della cache è breve, è possibile che WAE non sia in grado di gestire il volume di traffico.
Se la compressione DRE non è significativa, esaminare i contatori Nack/R-tx nella sezione seguente dell'output del comando:
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
. . .
I contatori Nack e R-tx dovrebbero in genere essere bassi rispetto al volume di traffico. Ad esempio, circa 1 per 100 MB di traffico originale (non ottimizzato). Se vengono visualizzati conteggi notevolmente più alti, è possibile che si sia verificato un problema di sincronizzazione della cache DRE. Utilizzare il comando clear cache dre per cancellare la cache DRE da tutti i dispositivi o contattare TAC.
I contatori dei motivi di bypass della codifica segnalano il numero di byte passati per vari motivi. Ciò consente di determinare la causa del traffico di bypass (diversa da un modello di dati non ottimizzabile).
A volte è utile identificare le WAE peer connesse e attive e osservare le statistiche peer, operazione che è possibile eseguire con il comando show statistics peer dre come segue:
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
. . .
Altri output di questo comando mostrano le statistiche di codifica e decodifica in modo simile a una singola connessione.