Este artículo describe cómo resolver problemas la optimización básica.
Las optimizaciones básicas WAAS incluyen la optimización del flujo TCP (TFO), la eliminación de la redundancia de datos (DRE), y la compresión persistente de Lempel-Ziv (LZ).
El número de conexiones TCP, de su estatus, y de disposición puede dar una indicación de la salud del sistema WAAS en una ubicación específica. Un sistema saludable mostrará un gran número de conexiones, con perceptiblemente un gran porcentaje de éstos cerrados normalmente. El comando detail del tfo de las estadísticas de la demostración proporciona a una indicación del volumen, del estatus, y de la disposición de las conexiones entre un dispositivo determinado WAAS y los otros dispositivos en la red.
Usted puede ver las estadísticas globales TFO usando el comando detail del tfo de las estadísticas de la demostración como sigue:
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 . . .
No de las conexiones activas coloca los informes el número de conexiones que se estén optimizando actualmente.
En la sección de las estadísticas del motor de directivas de la salida, razones rechazadas de la demostración de la sección de los recuentos de conexiones las diversas por las que se han rechazado las conexiones. El contador del límite de la conexión señala la cantidad de veces que se ha rechazado una conexión porque el número máximo de conexiones optimizadas se ha excedido. Si usted ve un número alto aquí, usted debe mirar en las condiciones de sobrecarga. Vea las condiciones de sobrecarga del troubleshooting del artículo para más información.
Además, la optimización TFO para las conexiones que se empujan hacia abajo del otro AOs porque no pueden optimizar el tráfico es manejada por el AO genérico, que se cubre en el artículo que resuelve problemas el AO genérico.
Usted puede ver las estadísticas de conexión TFO usando el comando connection de las estadísticas de la demostración. Para los detalles en usar este comando, vea la sección “controlando las conexiones TCP optimizadas” en el artículo de las condiciones de sobrecarga del troubleshooting.
Cuando se espera pero no se observa la aceleración de la aplicación, verifique que las optimizaciones apropiadas se estén aplicando al flujo de tráfico y que el caché DRE está reduciendo el tamaño del tráfico optimizado apropiadamente.
Las correspondencias del motor de directivas para la optimización DRE y LZ incluyen el siguiente:
Las diversas condiciones podrían causar DRE y/o LZ que no se aplicarán a una conexión, aunque se configura:
Nota: En todas las condiciones antedichas, el comando connection de las estadísticas de la demostración señalará la aceleración de “TDL” para las conexiones donde estaba la directiva ésta negociada. Mirando la cantidad el tráfico de puente DRE o LZ le dirá si las optimizaciones DRE o LZ eran realmente aplicadas. Utilice el comando conec-identificación de la conexión de las estadísticas de la demostración, según lo descrito más adelante, y la mirada en el DRE codifica los números para considerar si la relación de transformación DRE o LZ está cerca del 0% y la mayor parte del tráfico se desvía. Las primeras tres condiciones serán señaladas por “codifican puente debido” colocar y las tres condiciones pasadas resultan del modelo de los datos del tráfico y se explican en las relaciones de transformación señaladas DRE y LZ.
Usted puede ver las estadísticas para que una conexión específica determine qué optimizaciones básicas fueron configuradas, negociadas con el par, y aplicadas usando el comando conec-identificación de la conexión de las estadísticas de la demostración. Primero usted necesitará determinar el ID de conexión para una conexión determinada usando el comando connection de las estadísticas de la demostración, como sigue:
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% <------
Usted encontrará los ID de conexiones para cada conexión enumerada en el extremo de la salida. Para ver las estadísticas para una conexión específica, utilice el comando conec-identificación de la conexión de las estadísticas de la demostración, como sigue:
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 . . .
Los campos de nombre del nombre de la aplicación y del clasificador le dicen la aplicación y el clasificador aplicados a esta conexión.
Las directivas de la optimización se enumeran en la sección de los detalles de la directiva. Si las directivas configuradas y aplicadas no hacen juego, significa que usted configuró una directiva para este tipo de conexión pero una diversa directiva era aplicada. Esto podía resultar del par que estaba abajo, misconfigured, o sobrecargó. Controle el par WAE y su configuración.
La sección siguiente de las demostraciones DRE de la salida codifica/las estadísticas decodificar-relacionadas incluyendo el número de mensajes, cuántos tenían DRE aplicado, LZ aplicado, o desvió DRE y 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 . . .
Las estadísticas siguientes se destacan en el ejemplo antedicho para la codificación y decodificar:
Si usted ve una gran cantidad de tráfico de puente, la proporción de compresión DRE será más pequeña que esperada. Podría ser debido al tráfico encriptado, a los pequeños mensajes, o a los datos de otra manera uncompressible. Consider TAC que entra en contacto con para la ayuda adicional del troubleshooting.
Si usted ve una gran cantidad de tráfico de puente LZ, esto podría ser debido a una gran cantidad de tráfico encriptado, que no es generalmente compresible.
Latencia promedio los números pueden ser útiles para poner a punto un problema de la producción. Dependiendo de la plataforma, la codificación y decodifica latencia promedio está típicamente en los solos dígitos del ms. Si los usuarios experimentan el bajo rendimiento y un o ambo números son más altos, indica un problema con la codificación o decodificar, generalmente en el lado con la latencia más alta.
Puede ser útil mirar los datos estadísticos DRE tales como los más viejos datos usables, tamaño de la memoria caché, el por ciento del caché usado, RAM de la tabla de hash usado, y así sucesivamente usando el comando detail del dre de las estadísticas de la demostración, como sigue:
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 . . .
Si usted no está viendo la compresión significativa DRE, podría ser porque el caché DRE no se puebla con bastantes datos. Controle si la edad del caché es corta y el menos de 100 por ciento del caché se utiliza, que indicaría esta situación. La proporción de compresión debe mejorar mientras que el caché llena de más datos. Si el 100% del caché se utiliza y la edad del caché es corta, indica que el WAE puede poder de tamaño insuficiente y no manejar el volumen de tráfico.
Si usted no está viendo la compresión significativa DRE, mire los contadores Nack/R-tx en la sección siguiente del comando hecha salir:
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 . . .
Los contadores de Nacks y de R-tx deben generalmente ser bajos en relación con el volumen de tráfico. Por ejemplo, cerca de 1 por el 100 MB del tráfico (unoptimized) original. Si usted ve registros perceptiblemente más altos, podría indicar un problema de sincronización del caché DRE. Utilice el comando claro del dre del caché de borrar el caché DRE en todos los dispositivos, o entre en contacto con TAC.
Las razones de puente de la codificación contradicen el informe el desviada cantidad de bytes debido a las diversas razones. Esto puede ayudarle a determinar qué está causando el tráfico de puente (con excepción de un modelo unoptimizable de los datos).
Es a veces útil identificar haber conectado y al peer activo WAEs y mirar las estadísticas del par, que usted puede hacer con el comando del dre del par de las estadísticas de la demostración como sigue:
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 . . .
La otra salida de este comando muestra la codificación y decodifica las estadísticas similares a una conexión individual.