Por que meu servidor da web está descartando conexões com uma redefinição de TCP com carga alta?

Question

Eu tenho uma pequena configuração VPS com nginx. Eu quero extrair o máximo possível de desempenho, então experimento com otimização e teste de carga.

Estou usando o Blitz.io para fazer testes de carga, obtendo um pequeno arquivo de texto estático e executando um problema estranho em que o servidor parece estar enviando redefinições TCP quando o número de conexões simultâneas atinge aproximadamente 2000. Eu sei disso é muito grande, mas ao usar o htop, o servidor ainda tem muito o que poupar em tempo e memória da CPU, por isso, gostaria de descobrir a origem desse problema para ver se posso fazer isso ainda mais.

Estou executando o Ubuntu 14.04 LTS (64 bits) em um Linode VPS de 2 GB.

Eu não tenho reputação suficiente para postar este gráfico diretamente, então aqui está um link para o gráfico Blitz.io:

Aquiestãoalgumascoisasquefizparatentardescobriraorigemdoproblema:

• Ovalordeconfiguraçãodonginxworker_rlimit_nofileestádefinidocomo8192
• temnofiledefinidocomo64000paralimitesrígidoseflexíveispararootewww-datauser(emquenginxéexecutado)em/etc/security/limits.conf

• nãoháindicaçõesdequealgoestáerradoem/var/log/nginx.d/error.log(normalmente,sevocêestiverexecutandoemlimitesdedescritordearquivo,onginximprimirámensagensdeerrodizendo)

• Eutenhoaconfiguraçãoufw,masnãoháregrasdelimitaçãodetaxa.Ologdoufwindicaquenadaestásendobloqueadoeeutenteidesabilitaroufwcomomesmoresultado.

• Nãoháerrosindicativosem/var/log/kern.log
• Nãoháerrosindicativosem/var/log/syslog

• Euadicioneiosseguintesvaloresa/etc/sysctl.confeoscarregueicomsysctl-psemefeito:

  net.ipv4.tcp_max_syn_backlog=1024net.core.somaxconn=1024net.core.netdev_max_backlog=2000

Algumaidéia?

EDIT:Eufizumnovoteste,aumentandopara3000conexõesemumarquivomuitopequeno(apenas3bytes).AquiestáográficoBlitz.io:

Mais uma vez, de acordo com o Blitz, todos esses erros são erros "TCP Connection reset".

Aqui está o gráfico de largura de banda Linode. Tenha em mente que esta é uma média de 5 minutos, então é baixa passagem filtrada um pouco (largura de banda instantânea é provavelmente muito maior), mas ainda assim, isso não é nada:

CPU:

E / S:

Aquiestáhtoppertodofinaldoteste:

Eu também capturei parte do tráfego usando o tcpdump em um teste diferente (mas de aparência semelhante), iniciando a captura quando os erros começaram a aparecer: sudo tcpdump -nSi eth0 -w /tmp/loadtest.pcap -s0 port 80

Aqui está o arquivo se alguém quiser dar uma olhada nele (~ 20MB): link

Aqui está um gráfico de largura de banda do Wireshark:

(Linha é todos os pacotes, barras azuis são erros do TCP)

Da minha interpretação da captura (e eu não sou especialista), parece que os sinalizadores TCP RST estão vindo da fonte de teste de carga, não do servidor. Portanto, supondo que algo não esteja errado no lado do serviço de teste de carga, é seguro assumir que esse é o resultado de algum tipo de gerenciamento de rede ou de redução de DDOS entre o serviço de teste de carga e meu servidor?

Obrigado!

    

Answer 1

Por favor, olhe quantas portas estão em TIME_WAIT state usando o comando netstat -patunl| grep TIME | wc -l e altere net.ipv4.tcp_tw_reuse para 1.

    

Answer 2

Pode haver qualquer número de origens da conexão redefinida. O testador de carga pode estar sem portas efêmeras disponíveis a partir das quais iniciar uma conexão, um dispositivo ao longo do caminho (como um firewall fazendo NAT) pode ter seu pool NAT esgotado e não é possível fornecer uma porta de origem para a conexão um balanceador de carga ou firewall no seu final que pode ter atingido um limite de conexão? E, se estiver fazendo NAT de origem no tráfego de entrada, isso também pode causar exaustão de porta.

Alguém realmente precisaria de um arquivo pcap de ambas as extremidades. O que você deseja procurar é se uma tentativa de conexão for enviada, mas nunca chegar ao servidor, mas ainda aparecer como se tivesse sido redefinida pelo servidor. Se for esse o caso, algo ao longo da linha teve que redefinir a conexão. A exaustão da piscina NAT é uma fonte comum desses tipos de problemas.

Além disso, o netstat -st pode fornecer algumas informações adicionais.

    

Answer 3

Algumas ideias para tentar, com base nas minhas próprias experiências de ajuste semelhantes recentes. Com referências:

Você diz que é um arquivo de texto estático. Apenas no caso de haver algum processamento upstream acontecendo, aparentemente os soquetes de domínio melhoram o throughput de TCP em uma conexão baseada em porta TC:

link link

Independentemente da terminação de upstream:

Ativar multi_accept e tcp_nodelay: link

Desativar o início lento do TCP: link link

Otimizar janela de congestionamento TCP (initcwnd): link

    

Answer 4

Para definir o número máximo de arquivos abertos (se isso está causando o seu problema) você precisa adicionar "fs.file-max = 64000" ao /etc/sysctl.conf