Verniz ficando sem portas abertas, muitas conexões SYN_SENT

Recentemente, tivemos problemas com a nossa configuração de verniz (3x) -> Apache (3x), resultando em um grande aumento nas SYN_SENTconexões.

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

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

De que lado está a culpa? A quantidade de tráfego é significativa, mas de maneira alguma deve causar a instalação (3x máquinas front-end Varnish, 3x servidores Apache back-end).

Por favor ajude.

A captura de tela do Munin para conexões por firewall está 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

Seu problema provavelmente está com o sysctl nos servidores Apache.

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

Portanto, os recursos em seus servidores Apache podem ser amplos, mas as solicitações terão que ser colocadas em fila em algum lugar, mesmo que por pouco tempo. No momento, eles não estão na fila de maneira saudável, onde acabam sendo processados.

Parece que seus pedidos estão presos no Varnish e não chegam aos servidores Apache.

Há alguma evidência para isso:

Observe no seu gráfico munin, antes que os SYN_SENTs sejam copiados, as solicitações em TIME_WAIT aumentam e, depois de um ponto, elas começam a se acumular como SYN_SENTS. Isso indica que as solicitações estão começando a ser respondidas mais lentamente, depois a fila faz backup e as solicitações não são respondidas.

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

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 servidor Varnish.

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

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

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

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

Você provavelmente não deve ajustar o net.ipv4.tcp_mem. Observe que a unidade desse parâmetro está em páginas, não em bytes, portanto, copiar o mesmo valor de net.ipv4.tcp_rmem ou net.ipv4.tcp_wmem (ambos em bytes) não faz sentido. Ele é ajustado automaticamente pelo Linux com base na sua quantidade de memória e, portanto, raramente precisa de ajustes. De fato, esse pode ser o seu problema, limitando arbitrariamente a memória disponível para o enfileiramento geral de conexões.

Veja: http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/

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.

No servidor Varnish, tente alterar estes 2 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.