Temos um servidor dedicado alugado em um data center com o debian 7, kernel 3.2.
Nós usamos um desses servidores como um servidor de banco de dados. A rede entre o nosso servidor de aplicativos e o servidor de banco de dados não é dedicada a nós, mas é usada por outros clientes do data center.
De tempos em tempos, reconhecemos as retransmissões TCP nessa linha. Nós pensamos que é devido ao congestionamento ou ataques de ddos. Nosso provedor tenta impedir ataques, mas nem sempre é bem-sucedido imediatamente.
De qualquer forma. Normalmente, nosso servidor de aplicativos obtém resultados do banco de dados em 20 milissegundos, pois os servidores de banco de dados são muito rápidos e a média do tempo de ida e volta (RTT) é de 0,3 ms (portanto, abaixo de 1 ms).
Quando um pacote TCP é perdido nesta linha, o tempo limite de retransmissão (RTO) é ativado. Ele é calculado pelo tempo de ida e volta, mas é pelo menos 200 ms. Portanto, quando um pacote precisa ser retransmitido, temos 220 milissegundos antes que nosso servidor de aplicativos obtenha seus dados apenas por causa do RTO.
Para mim, rto_min = 200ms parece ser o caminho mais alto para um link com o rtt em 1ms.
É possível definir o rto_min com ip
da seguinte forma:
ip route change default via 144.76.176.65 dev eth0 rto_min 5ms
O RTO ainda é calculado, mas pode chegar a 5 ms, já que nosso RTT é muito pequeno.
Devo considerar isso ou existem outras armadilhas do TCP nas quais configurarei o rto_min tão pequeno? O que é um valor razoável para rto_min ou é melhor não tocá-lo?
Tags networking linux tcp linux-kernel