Varnish esgotando as portas abertas, muitas conexões SYN_SENT

Question

Recentemente, enfrentamos problemas com nosso verniz (3x) - > Configuração do Apache (3x), resultando em um grande pico em SYN_SENT conexões.

O pico em si é devido à quantidade de tráfego novo atingindo o site (não um DDOS de qualquer tipo), e parece que nossas máquinas de verniz estão tendo problemas para encaminhar o tráfego para os servidores backend (queda no tráfego do Apache está correlacionada a picos nos vernizes), congestionando o conjunto de portas disponíveis com SYN_SENT .

Keep-alives estão habilitados no Apache (15s).

De que lado está a falha? A quantidade de tráfego é significativa, mas não deve fazer com que tal configuração (3x máquinas frontend Varnish, 3x servidores Apache backend) parem.

Por favor ajude.

A captura de tela do Munin para conexões por firewall é aqui .

Verniz ~$ netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

      9 CLOSE_WAIT
     12 CLOSING
    718 ESTABLISHED
     39 FIN_WAIT1
   1714 FIN_WAIT2
     76 LAST_ACK
     12 LISTEN
    256 SYN_RECV
   6124 TIME_WAIT

/etc/sysctl.conf (verniz)

net.ipv4.netfilter.ip_conntrack_max = 262144
net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv = 60
net.ipv4.ip_local_port_range = 1024 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem=4096 87380 16777216
net.ipv4.tcp_wmem=4096 65536 16777216
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_fin_timeout = 30

Apache netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c

     11 CLOSE_WAIT
    286 ESTABLISHED
     38 FIN_WAIT2
     14 LISTEN
   7220 TIME_WAIT

/etc/sysctl.conf (Apache)

vm.swappiness=10
net.core.wmem_max = 524288
net.core.wmem_default = 262144
net.core.rmem_default = 262144
net.core.rmem_max = 524288
net.ipv4.tcp_rmem = 4096 262144 524288
net.ipv4.tcp_wmem = 4096 262144 524288
net.ipv4.tcp_mem = 4096 262144 524288

net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_max_syn_backlog = 16384
net.ipv4.tcp_keepalive_time = 30

net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.core.somaxconn = 2048


net.ipv4.conf.lo.arp_ignore=8
net.ipv4.conf.all.arp_ignore=1
net.ipv4.conf.all.arp_announce=2

vm.swappiness = 0

kernel.sysrq=1
kernel.panic = 30

    

Answer 1

Seu problema provavelmente é com o sysctl nos servidores Apache.

Algumas suposições: Normalmente, o Varnish é muito mais rápido no processamento de cada conexão do que em um servidor da Web (a menos que seus servidores Varnish tenham muito menos CPU e seus servidores Apache estejam apenas servindo arquivos estáticos armazenados em cache na memória). Apache.

Portanto, os recursos em seus servidores Apache podem ser amplos, mas as solicitações terão que ficar em fila em algum lugar, ainda que muito brevemente. No momento, eles não estão fazendo fila de uma maneira saudável, onde acabam sendo processados.

Parece que suas solicitações estão ficando presas no verniz e não estão sendo feitas nos servidores Apache.

Há alguma evidência para isso:

Observe que, antes de fazer o backup dos SYN_SENTs, os pedidos em TIME_WAIT aumentam, depois de um ponto, eles começam a acumular-se como SYN_SENTS. Isso indica que as solicitações estão começando a ser respondidas mais lentamente, depois a fila faz o backup e as solicitações não são respondidas.

Isso indica para mim que o seu servidor Apache não está aceitando conexões suficientes (onde eles podem se sentar e fazer fila para o Apache processá-los.)

Eu vejo vários limites possíveis no seu arquivo de configuração:

Quando você tem pico, você tem aproximadamente 30000 conexões no estado SYN_SENT no seu servidor Varnish.

No entanto, no servidor Apache seu max_syn_backlog é apenas 16384. Seu somaxconn é apenas 2048.

Observe também que o tamanho de seus buffers de memória de rede nos servidores Apache é muito baixo. Você os ajustou no servidor Varnish para 16MB. Mas no servidor Apache seu net.ipv4.tcp_rmem é de apenas 524KB para corresponder ao seu net.core.rmem_max.

Eu recomendo aumentar todos esses parâmetros no servidor Apache.

Você precisará se concentrar mais nos diagnósticos do servidor Apache para descobrir exatamente o que está acontecendo, mas talvez não seja necessário aumentar esses valores.

Você provavelmente não deve ajustar net.ipv4.tcp_mem. Observe que a unidade para este parâmetro está em páginas, não em bytes, copiando assim o mesmo valor de net.ipv4.tcp_rmem ou net.ipv4.tcp_wmem (ambos em bytes) não faz qualquer sentido. É sintonizado automaticamente pelo linux com base na sua quantidade de memória, por isso raramente precisa de ajuste. Na verdade, esse pode ser o seu problema, limitando arbitrariamente a memória disponível para o enfileiramento geral de conexões.

Veja: link

Observe também que "vm.swappiness = 0" está definido duas vezes, uma vez como 10 e novamente na parte inferior como 0, que é o valor efetivo.

    

Answer 2

No servidor Varnish, tente alterar esses dois parâmetros:

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 1

tw_reuse permitirá reutilizar as conexões em TIME_WAIT.

tw_recycle pode causar problemas com balanceadores de carga, etc.