El barniz se está quedando sin puertos abiertos, muchas conexiones SYN_SENT

Recientemente hemos estado experimentando problemas con nuestra configuración Varnish (3x) -> Apache (3x), lo que resulta en un gran aumento en las SYN_SENTconexiones.

El pico en sí se debe a la cantidad de tráfico nuevo que llega al sitio (no un DDOS de ningún tipo), y parece que nuestras máquinas Varnish están teniendo problemas para reenviar el tráfico a los servidores de fondo (la caída del tráfico de Apache se correlaciona con los picos en los barnices). ), congestionando el conjunto de puertos disponibles con SYN_SENT.

Keep-Alives están habilitados en Apache (15s).

¿De qué lado es la culpa? La cantidad de tráfico es significativa, pero de ninguna manera debería causar que dicha configuración (3x máquinas de interfaz de barniz, 3x servidores Apache back-end) se bloquee.

Por favor ayuda.

La captura de pantalla de Munin para las conexiones a través del firewall está aquí .

Barniz ~$ 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 (Barniz)

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

Su problema probablemente sea con el sysctl en los servidores Apache.

Algunas suposiciones: por lo general, Varnish es mucho más rápido en el procesamiento de cada conexión que un servidor web (a menos que tal vez sus servidores Varnish tengan mucha menos CPU y sus servidores Apache solo sirvan archivos estáticos almacenados en la memoria caché). Asumiré que sus conexiones se procesan más rápido en barniz que apache.

Por lo tanto, los recursos en sus servidores Apache pueden ser amplios, pero las solicitudes tendrán que hacer cola en algún lugar, aunque sea muy brevemente. En este momento no están haciendo cola de una manera saludable donde eventualmente se procesan.

Parece que sus solicitudes se estancan en Varnish y no llegan a los servidores Apache.

Hay alguna evidencia de esto:

Observe en su gráfico munin, antes de que se realicen copias de seguridad de SYN_SENT, las solicitudes en TIME_WAIT aumentan, luego, después de un punto, comienzan a acumularse como SYN_SENTS. Esto indica que las solicitudes comienzan a ser respondidas más lentamente, luego la cola retrocede y las solicitudes no reciben ninguna respuesta.

Esto me indica que su servidor Apache no acepta suficientes conexiones (donde pueden sentarse y hacer cola para que Apache las procese).

Veo varios límites posibles en su archivo de configuración:

Cuando tiene un pico, tiene aproximadamente 30000 conexiones en el estado SYN_SENT en su servidor Varnish.

Sin embargo, en el servidor Apache su max_syn_backlog es solo 16384. Su somaxconn es solo 2048.

Observe también que el tamaño de sus memorias intermedias de memoria de red en los servidores Apache es muy bajo. Los ha ajustado en el servidor Varnish a 16 MB. Pero en el servidor Apache, su net.ipv4.tcp_rmem solo tiene 524 KB para que coincida con su net.core.rmem_max.

Recomiendo elevar todos estos parámetros en el servidor Apache.

Tendrá que centrarse más en los diagnósticos en el servidor Apache para averiguar exactamente lo que está sucediendo, pero es posible que no necesite hacerlo si aumenta estos valores.

Probablemente no debería ajustar net.ipv4.tcp_mem. Tenga en cuenta que la unidad para este parámetro está en páginas, no en bytes, por lo que no tiene sentido copiar el mismo valor de net.ipv4.tcp_rmem o net.ipv4.tcp_wmem (ambos en bytes). Linux lo ajusta automáticamente en función de su cantidad de memoria, por lo que rara vez necesita ajustes. De hecho, este puede ser su problema, ya que limita arbitrariamente la memoria disponible para la cola de conexión general.

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

Observe también que su "vm.swappiness = 0" se establece dos veces, una vez como 10, y nuevamente en la parte inferior como 0, que es el valor efectivo.

En el servidor Varnish, intente cambiar estos 2 parámetros:

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

tw_reuse le permitirá reutilizar las conexiones en TIME_WAIT.

tw_recycle podría causar problemas con los equilibradores de carga, etc.