Comportamento da pilha solaris tcp com tráfego RTT e rajadas relativamente alto

Question

Eu tenho um aplicativo que está distribuindo dados de Nova York para Tóquio sobre TCP executando o Solaris 10. A taxa de transferência média é < 1Mbps, a taxa de transferência de pico pode atingir 20-30Mbps por segundo de cada vez, embora os picos típicos sejam mais de 10Mbps. Os tamanhos das mensagens individuais são pequenos (~ 300 bytes) e a consistência da latência é fundamental. Isso significa que estamos tentando remover os lotes, também conhecidos como nagles off & aplicativo está configurado para enviar o mais rápido possível ao invés de enviar e enviar.

O RTT entre Nova York e Tóquio é de ~ 180 ms e a janela TCP é ajustada para uma taxa de transferência teórica na região de ~ 40Mbps, também conhecida como 1M tcp_xmit_hiwat / tcp_rcv_hiwat. tcp_max_buf e tcp_cwnd_max também são 1M.

O problema aqui é que frequentemente, mas intermitentemente, vemos "pausas" misteriosas onde o remetente obtém EWOULDBLOCK levando a um acúmulo em uma fila interna e, em seguida, a subseqüente descarga de dados. Existem 2 problemas aqui

1. não há razão óbvia para o soquete de bloqueio, parece que não estamos atingindo o pico de taxa de transferência e nada nas capturas de pacote sugere lentidão
2. durante o "período de descarga" (ou seja, quando a tomada do remetente não está mais bloqueando, mas tem um buffer de dados para enviar), vemos um padrão dente de serra cada vez maior nas taxas de mensagens

O primeiro é a chave para o problema, se eu puder resolver isso, o último não deve ocorrer. No entanto, o último é estranho, eu estava ingenuamente esperando que ele aumentasse rapidamente a taxa de transferência e permanecesse lá até que tivesse passado pelo backlog.

A utilização da CPU não é um problema em ambas as extremidades, as caixas dizem que as caixas parecem boas. O congestionamento da rede no link WAN também não é um problema, as redes dizem que a rede parece boa. Na verdade, todo mundo diz que cada peça parece bem, ela ainda está se saindo mal!

Alguma idéia de como otimizar essa situação? ou coisas para investigar que podem fornecer uma pista sobre o que está acontecendo?

    

Answer 1

EWOULDBLOCK / EAGAIN significa que os dados não puderam ser enviados imediatamente. Precisamos de mais detalhes sobre o seu código para descobrir isso.

• Tente descobrir o que acontece no lado do remetente quando o EWOULDBLOCK é retornado. Verifique se há threads e outros processos, monitore a memória / troca e o uso da cpu. Verifique seus logs (/ var / messages, ...) por qualquer erro de hardware.
• Determinar a perda de pacotes
• Execute o programa em outro SO antes de acusar a pilha TCP do Solaris ou escreva um pequeno programa de teste que envie 300B / s para o terminal remoto (sem necessidade de soquetes sem bloqueio, apenas envie), verifique se há latência o problema da rede.

Eu não sou um desenvolvedor, mas sugiro que você tente substituir sockets sem bloqueio por um multiplexador de E / S: selecione ou poll ou / dev / poll e verifique se o socket está pronto para gravação. Pode mudar o comportamento do seu programa para melhor ou, na pior das hipóteses, dar-lhe mais debug e dicas sobre o problema real.

Em distâncias tão longas, todos os pacotes provavelmente estão usando rotas diferentes, embora com um AS diferente, para que ninguém possa realmente avaliar a qualidade da rede. Um pacote pode levar muito tempo para chegar e ser reconhecido por causa de um problema em algum ponto da internet (provavelmente está próximo, caso contrário as pessoas teriam informado e corrigido), tente entrar de / para outros locais. Se um único pacote demorar muito para ser reconhecido, a janela TCP ficará presa e os dados adicionais poderão não ser processados. Você pode tentar ajustar o tamanho da janela TCP para um valor mais alto.

Além disso, você pode simplesmente executar mtr para verificar rapidamente a qualidade da rede. Execute-o várias vezes, pois os pacotes podem seguir caminhos diferentes.

Espero que isso tenha ajudado, de alguma forma: /