Guía de Troubleshooting de Cisco WAAS para la versión 4.1.3 y más adelante
Capítulo: Resolver problemas la optimización
Este artículo describe cómo resolver problemas la optimización básica.
Artículo principal
Comprensión de la arquitectura y del flujo de tráfico WAAS
Troubleshooting preliminar WAAS
Resolver problemas la optimización
Resolver problemas la aceleración de la aplicación
Resolver problemas el CIFS AO
Resolver problemas el HTTP AO
Resolver problemas el EPM AO
Resolver problemas el MAPI AO
Resolver problemas el NFS AO
Resolver problemas el SSL AO
Resolver problemas el vídeo AO
Resolver problemas el AO genérico
Resolver problemas las condiciones de sobrecarga
Resolver problemas el WCCP
Resolver problemas AppNav
Resolver problemas el disco y los problemas de hardware
Resolver problemas los racimos en línea seriales
Resolver problemas el vWAAS
Resolviendo problemas WAAS expreso
Resolver problemas la integración NAM
Contenido
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).
Troubleshooting TFO
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.
Troubleshooting DRE
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:
- DRE + LZ (lleno): la correspondencia de la aplicación del motor de directivas otra optimiza por completo
- DRE solamente: la correspondencia de la aplicación del motor de directivas otra optimiza la compresión DRE sí ningunos
- LZ solamente: la correspondencia de la aplicación del motor de directivas otra optimiza DRE ninguna compresión LZ
- Paso TFO: correspondencia de la aplicación del motor de directivas el otro paso
Las diversas condiciones podrían causar DRE y/o LZ que no se aplicarán a una conexión, aunque se configura:
- La inicialización del caché está en curso
- Errores entrada-salida del disco
- Memoria baja
- Los datos no son compresibles o el aumento es demasiado pequeño
- Los datos se cifran tales que no contienen las secuencias de bytes relanzadas
- Los mensajes son demasiado pequeños beneficiarse de la compresión
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:
- Relación de transformación total - la proporción de compresión total para los datos incluyendo DRE y LZ
- Relación de transformación DRE - la proporción de compresión debido a DRE solamente
- Puente DRE - el número de mensajes y de bytes que desviaron DRE
- Relación de transformación LZ - la proporción de compresión debido a LZ solamente
- Puente LZ - el número de mensajes y de bytes que desviaron LZ
- El tiempo de espera de Avg - latencia promedio para la codificación o decodifica la operación
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.
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)