¿Cómo encontrar la fuente del aumento de la latencia?


14

Tengo la configuración de monitoreo en varios dispositivos en nuestra oficina. El tiempo de respuesta de ping a los conmutadores de acceso pequeños es comúnmente de 1-4 ms ... A partir de las 3 a.m. de esta mañana, esto se ha disparado a 300 ms en promedio.

¿Dónde se empieza a mirar en una situación como esta? ¿Qué cosas puedo observar en el interruptor para encontrar la fuente de latencia?

NOTA: No está relacionado con la carga ... todos los enlaces de ancho de banda son normales y no se ven afectados, la mayoría de los enlaces están muy infrautilizados. Además, el monitoreo es local para los dispositivos que informan la latencia, por lo que no hay factor WAN aquí.


3
Suponiendo que se trata de un conmutador Cisco IOS ... Publique show proc cpu historypara el conmutador con los tiempos de ping altos. Si esa CPU es consistentemente alta, o se dispara regularmente, ejecuteshow proc cpu sort
Mike Pennington

¿La latencia es solo hacia el plano de control del interruptor o se obtiene la misma latencia cuando se hace ping a algo detrás del interruptor?
ytti

@MikePennington - imgur.com/a/gfX9q#0 - ¡esto es genial! Parece que se dispara bastante alto constantemente, aunque en promedio es bajo ...
AL

@Ytti - no quise publicar esto en una línea separada ... de todos modos - Así que profundicé en esto. La respuesta de cp <-> cp es realmente baja desde la distribución hasta el acceso, o al menos lo fue en el momento en que lo probé. Desde un puerto de nivel de acceso a los dispositivos en los conmutadores de capa de acceso es donde vemos la latencia extrema.
AL

@ user1353, gracias ... esa imgur que publicó no es lo suficientemente alta como para causar un aumento constante de los tiempos de ping de la CPU en ese interruptor
Mike Pennington

Respuestas:


6

Primero, la latencia no está directamente relacionada con el ancho de banda. Hay muchas razones por las cuales un dispositivo retrasaría un paquete que no sea un enlace congestionado.

¿Has intentado una traceroute? Esto le mostrará la latencia entre saltos, si está buscando un límite L3 como sospechoso.

También puede verificar si alguno de los dispositivos en la ruta tiene un uso significativo de CPU / RAM.


Estoy de acuerdo con Mierdin y también recomiendo MTR para ejecutar continuamente un traceroute en este tipo de situación. Enlace de Wikipedia: en.m.wikipedia.org/wiki/MTR_(software)
Brett Lykins

@Mierdin: gracias por sus comentarios, por lo que no hay un factor L3 aquí, traceroute muestra una respuesta inicialmente alta de aproximadamente 500 ms, luego 260 ms, luego 76 ms llegando al dispositivo; estos son para cada intento en el mismo salto único, no para múltiples lúpulo Vea mi comentario a MikePennington para obtener información relacionada con la CPU.
AL

3

Si esto se basa únicamente en la LAN, hay algunas cosas que puede hacer para comenzar y tratar de descubrir qué está causando esto:

  • Comando Show process cpu history : si el uso de la CPU es muy alto, entonces necesita ver qué proceso está causando esto y quizás golpear google con el proceso ofensivo.

  • comando show debug : una causa común que he encontrado es que las personas dejan comandos de depuración ejecutándose en el switch. Un favorito común era la contabilidad IP que se dejaba en dispositivos que ya estaban sobreutilizados. Use "undebug all" para deshacerse de los debugs.

  • Reinícielo : probablemente no durante el día, pero use el comando "recargar" para programarlo por la noche o durante el fin de semana. Te sorprendería cuántos problemas puede solucionar un reinicio rápido.

  • cerrar puertos troncales : si se trata de un conmutador L3, otro problema común que he visto es demasiado tráfico al usar este dispositivo para el enrutamiento entre VLAN. Si es posible, cierre temporalmente algunos de los puertos troncales para ver si esto reduce la latencia.

Es bueno tener en cuenta que sus pings son de baja prioridad, en lo que respecta a la latencia y también cuando la CPU los procesa. También podría ser una buena idea verificar la configuración de QoS y asegurarse de que no haya errores tontos que causen esto, por poco que sea poco probable.


Gran respuesta, ya había revisado la depuración del programa, y ​​no es posible reiniciar en este momento.
AL

2

Utilizo cactus para monitorear el ancho de banda y openNMS para monitorear la latencia. Si está monitoreando todos los dispositivos vinculados a este interruptor, puede ver un corolario entre el uso y la latencia. (Sé que dijiste que no es un problema de ancho de banda, pero nunca lo has hecho ahora). He visto interruptores de gama baja que se hunden con un uso intensivo, lo que causa mucha latencia. ¿Tiene algún dispositivo "tonto" que alimente este conmutador que pueda ser la fuente del hundimiento a pesar de que este conmutador no pasa mucho tráfico? Además, con Cacti puede sondear el uso de la CPU y puede ver un pico en el momento de la latencia.

Como se mencionó anteriormente, MTR o neotrace también son útiles para vigilar la situación y puede ver dónde comienza la latencia, que puede no ser este cambio en sí.


0

Si esto no está sucediendo en LAN, podría limitar el rendimiento del "puerto wan", esto forzará un mejor TDM. Pruebe algo alrededor del 80% de su rendimiento máximo y vea si le ayuda. Es posible que necesite modificar la cantidad de terminales.


Según tengo entendido, OP ha declarado claramente en la nota que esto no está relacionado con la carga.
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.