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.