ping tempo de resposta

Question

Eu tenho dois sites hospedados em dois centros de dados diferentes. Recentemente, um site se tornou muito lento. A resposta do ping do servidor de aplicativos para o servidor de banco de dados não é rápida o suficiente. Como faço para investigar o problema?

On fast server:
10 packets transmitted, 10 received, 0% packet loss, time 8998ms
rtt min/avg/max/mdev = 0.243/0.279/0.502/0.074 ms

On slow server:
21 packets transmitted, 21 received, 0% packet loss, time 20011ms
rtt min/avg/max/mdev = 1.131/1.816/3.584/0.560 ms

O comando tracert mostra o seguinte:

On fast server:
tracert db
traceroute to db (xxx.xxx.100.101), 30 hops max, 40 byte packets
 1  db (xxx.xxx.100.101)  0.552 ms  0.530 ms  0.527 ms

 On slow server:
tracert xxx.16.55.140
traceroute to xxx.16.55.140 (xxx.16.55.140), 30 hops max, 40 byte packets
 1  xxx.16.55.140 (xxx.16.55.140)  1.859 ms  1.845 ms  1.842 ms

    

Answer 1

Execute um mapeamento do servidor da Web para o servidor de banco de dados e veja onde a lentidão é relatada. Em seguida, confirme executando um caminho do servidor de banco de dados para o front-end da web. Use o endereço IP dos nós e não os nomes DNS. Como Womble apontou, poderia ser lentidão do rDNS.

FYI, pathping, como tracert, pode fornecer informações de caminho enganosas simplesmente com base em como os pacotes podem ser roteados de uma maneira e de outra maneira com base no congestionamento da rede. Além disso, o caminho de encaminhamento não é garantido para ser o mesmo com cada salto aumentado. No entanto, esses são tópicos estranhos neste momento. Seguindo em frente ...

Depois de determinar onde a lentidão é, você pode continuar a solucionar problemas. Pode ser que os próprios nós finais sejam a desaceleração se estiverem sob carga pesada ou configurados incorretamente de alguma forma. Se você descobrir qual é o nó lento, atualize suas perguntas com as informações adequadas.

    

Answer 2

Você pode usar o traceroute para ver se há um ponto ao longo do caminho que está atrasando tudo.

    

Answer 3

Traceroute ( mtr é ainda melhor) o caminho entre as duas máquinas, procurando por saltos específicos que adicionam muita latência. Depois de identificar o local, você pode procurar a causa (verifique as estatísticas de porta nos dois lados do link em questão para ver se há enfileiramento ou algum outro problema); você não está descartando pacotes (bem, não um número excessivo deles - 21 pings não é exatamente estatisticamente significante) então você provavelmente não está sobrecarregando os buffers em nenhum lugar.

No entanto, você ainda verá apenas 1,8ms de latência para o link "mais lento", o que realmente é excelente em relação a qualquer link de WAN. A menos que você esteja fazendo algo incrivelmente sensível à latência (como negociações em alta velocidade), estou lutando para imaginar como isso pode ser "muito lento" em qualquer sentido significativo.

    

Answer 4

10 pacotes transmitidos, 10 recebidos, 0% de perda de pacotes, tempo 8998ms

O 8998ms é uma enorme latência de rede. Você pode usar mtr para ver se está falhando em algum momento? A que distância fica a localização do data center? Está conectando a China dos EUA? Qual é a carga média do servidor?

    

Answer 5

Você afirma em sua pergunta que o site ficou lento e, em seguida, pergunta sobre os tempos de ping. É possível que o site seja lento por outras razões?

Se você estiver hospedando dois sites em dois datacenters diferentes com apenas um banco de dados, a largura de banda entre os dois datacenters poderá ser o fator limitante.

Pode valer a pena verificar quantos dados você está obtendo do banco de dados em cada consulta. Não é incomum ver 10MB voltando em uma consulta de banco de dados apenas para que a linguagem de script parse / mangle / descarte os dados até que haja apenas alguns KB para enviar ao usuário. Muitas pessoas usam "SELECT *" mesmo quando precisam apenas de um campo. Também vale a pena verificar quanto tráfego você pode ver na sua porta de banco de dados. Se você tiver apenas um link de 10Mb para o outro datacenter e estiver fazendo uma consulta de até 1MB, levará quase um segundo para chegar.

Se a latência for realmente o problema, e não a largura de banda, o uso de conexões persistentes pode ajudar, pois evita a criação de uma nova conexão tcp para cada consulta. A configuração de um banco de dados escravo somente leitura no segundo datacenter também pode ajudar, pois consultas somente leitura podem ser feitas localmente.

    

Answer 6

O desvio padrão ( mdev ) dos pacotes em "slow" é alto em relação ao avg. Eu diria que a rede está congestionada (no nível do host ou no switch / roteador)

Você pode tentar usar iperf no modo UDP, você terá uma quantidade de tremulação dessa maneira.