Como encontrar a fonte de maior latência?


14

Eu tenho a configuração de monitoramento em vários dispositivos em nosso escritório. O tempo de resposta do ping para pequenos comutadores de acesso é geralmente de 1 a 4ms ... A partir das 3h desta manhã, isso disparou para 300ms em média.

Onde alguém começa a procurar em uma situação como essa? Que coisas posso observar no switch para encontrar a fonte da latência?

NOTA: Não está relacionado à carga. Todo o uso da largura de banda dos links é normal e não é afetado, a maioria dos links é muito pouco utilizada. Além disso - o monitoramento é local para os dispositivos que relatam a latência, portanto não há fator de WAN aqui.


3
Supondo que este seja um switch Cisco IOS ... Poste show proc cpu historyno switch com os altos tempos de ping. Se isso CPU é consistentemente alta, ou spiking alta em uma base regular, executarshow proc cpu sort
Mike Pennington

A latência é apenas para o plano de controle do comutador ou você obtém a mesma latência quando executa ping em algo atrás do comutador?
ytti

@MikePennington - imgur.com/a/gfX9q#0 - isso é muito legal! Parece que ele picos muito alto de forma consistente que, em média, de baixo ..
AL

@ Ytti - não quis postar isso em uma linha separada .. enfim - então eu cavei mais fundo nisso. cp <-> a resposta cp é realmente baixa da distribuição para acessar, ou pelo menos era no momento em que testei. De uma porta no nível de acesso aos dispositivos nos switches da camada de acesso, é onde vemos a extrema latência.
AL

@ user1353, obrigado ... que imgur que você postou não é consistentemente alta o suficiente para causar consistentemente aumento dos tempos de ping da CPU em que o interruptor
Mike Pennington

Respostas:


6

Primeiro, a latência não está diretamente ligada à largura de banda. Há muitas razões pelas quais um dispositivo atrasaria um pacote diferente de um link congestionado.

Você já tentou um traceroute? Isso mostrará a latência entre os saltos, se você estiver procurando por um limite L3 como suspeito.

Você também pode verificar se algum dos dispositivos no caminho possui um uso significativo de CPU / RAM.


Concordo com Mierdin e também recomendo a MTR por executar continuamente um traceroute nesse tipo de situação. Link da Wikipedia: en.m.wikipedia.org/wiki/MTR_(software)
Brett Lykins

@Mierdin - Obrigado pelo seu feedback, para que não haja fator L3 aqui, o traceroute mostra uma resposta inicialmente alta de cerca de 500ms, depois 260ms e 76ms chegando ao dispositivo - estes são para cada tentativa no mesmo salto único, não para múltiplos lúpulo. Veja meu comentário para MikePennington para obter informações relacionadas à CPU.
AL

3

se isso é apenas baseado na LAN, há algumas coisas que você pode fazer para começar a tentar descobrir o que está causando isso:

  • Comando show process cpu history : se o uso da CPU for muito alto, você precisará ver qual processo está causando isso e talvez acessar o google com o processo incorreto.

  • comando show debug : uma causa comum que encontrei são as pessoas que deixam os comandos debug em execução no switch. Um favorito comum era a contabilidade de IP deixada em dispositivos que já estavam superutilizados. Use "undebug all" para se livrar dos debugs.

  • Faça uma reinicialização : provavelmente não possivelmente durante o dia, mas use o comando "recarregar" para cronometrar à noite ou no fim de semana. Você ficaria surpreso com quantos problemas uma reinicialização rápida pode corrigir.

  • portas de tronco fechadas - Se for um switch L3, outro problema comum que eu já vi é muito tráfego usando esse dispositivo para roteamento entre VLANs. Se possível, feche temporariamente algumas das portas do tronco para ver se isso reduz a latência.

É bom estar ciente de que seus pings são de baixa prioridade em relação à latência e também ao serem processados ​​pela CPU. Também pode ser uma boa idéia verificar novamente suas configurações de QoS e garantir que não haja erros bobos causando isso, por mais improvável que seja.


Ótimo feedback, eu já havia verificado a depuração do programa, e uma reinicialização não é possível no momento.
AL

2

Eu uso cactos para monitorar a largura de banda e openNMS para monitorar a latência. Se você estiver monitorando todos os dispositivos vinculados a essa opção, poderá ver um corolário entre o uso e a latência. (Eu sei que você disse que não é um problema de largura de banda, mas você nunca agora). Vi interruptores de extremidade inferior caírem sob uso pesado, o que causa muita latência. Você tem dispositivos "burros" alimentando esse comutador que podem ser a fonte da queda, mesmo que esse comutador não esteja passando muito tráfego. Também com cactos, você poderá pesquisar o uso da CPU e poderá ver um pico no momento da latência.

Como mencionado acima, o MTR ou o neotrace também são úteis para ficar de olho na situação e você pode ver onde a latência começa, o que pode não ser essa opção em si.


0

Se isso não estiver acontecendo na LAN, você poderá limitar a taxa de transmissão da "porta de entrada", isso forçará um TDM melhor. Experimente algo em torno de 80% do seu rendimento máximo e veja se isso ajuda. Pode ser necessário tweek, dependendo da quantidade de terminais.


Pelo que entendi, o OP declarou claramente na nota que isso não está relacionado à carga.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.