Vernis à court de ports ouverts, beaucoup de connexions SYN_SENT

Récemment, nous avons rencontré des problèmes avec notre configuration Varnish (3x) -> Apache (3x), ce qui a provoqué un énorme pic de SYN_SENTconnexions.

Le pic lui-même est dû à la quantité de nouveau trafic frappant le site (et non à un DDOS d'aucune sorte), et il semble que nos machines Varnish ont des problèmes pour transmettre du trafic vers les serveurs principaux (le trafic Apache est corrélé aux pics sur les vernis). ), encombrant le pool de ports disponibles avec SYN_SENT.

Les Keep-Alives sont activés sur Apache (15s).

De quel côté est la faute? La quantité de trafic est importante, mais elle ne devrait en aucun cas provoquer le blocage d'une telle configuration (3 machines frontales Varnish, 3 serveurs Apache backend).

Veuillez aider.

La capture d'écran de Munin pour les connexions via le pare-feu est ici .

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

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

Votre problème est probablement avec le sysctl sur les serveurs Apache.

Quelques hypothèses: En général, Varnish est beaucoup plus rapide à traiter chaque connexion qu'un serveur Web (à moins que vos serveurs Varnish aient beaucoup moins de CPU et que vos serveurs Apache ne servent que des fichiers statiques mis en cache en mémoire.) Je vais supposer que votre processus de connexion est plus rapide en vernis que Apache.

Par conséquent, les ressources sur vos serveurs Apache peuvent être suffisantes, mais les demandes devront être mises en file d'attente quelque part, ne serait-ce que très brièvement. À l'heure actuelle, ils ne font pas la queue d'une manière saine où ils finissent par être traités.

Il semble que vos demandes soient bloquées dans Varnish et ne parviennent pas aux serveurs Apache.

Il y a des preuves pour cela:

Remarquez dans votre graphique munin, avant que les SYN_SENT ne soient sauvegardés, les demandes dans TIME_WAIT augmentent, puis après un point, elles commencent à s'accumuler en tant que SYN_SENTS. Cela indique que les demandes commencent à recevoir des réponses plus lentement, puis la file d'attente est sauvegardée et les demandes ne reçoivent aucune réponse.

Cela m'indique que votre serveur Apache n'accepte pas suffisamment de connexions (où ils peuvent ensuite s'asseoir et faire la queue pour qu'Apache les traite.)

Je vois plusieurs limites possibles dans votre fichier de configuration:

Lorsque vous avez un pic, vous disposez d'environ 30000 connexions à l'état SYN_SENT sur votre serveur Varnish.

Cependant, sur le serveur Apache, votre max_syn_backlog n'est que de 16384. Votre somaxconn n'est que de 2048.

Notez également que la taille de vos mémoires tampons réseau sur les serveurs Apache est très faible. Vous les avez ajustés sur le serveur Varnish à 16 Mo. Mais sur le serveur Apache, votre net.ipv4.tcp_rmem ne fait que 524 Ko pour correspondre à votre net.core.rmem_max.

Je recommande d'augmenter tous ces paramètres sur le serveur Apache.

Vous devrez vous concentrer davantage sur les diagnostics sur le serveur Apache pour savoir exactement ce qui se passe, mais vous n'aurez peut-être pas besoin de le faire si vous augmentez ces valeurs.

Vous ne devriez probablement pas ajuster net.ipv4.tcp_mem. Notez que l'unité de ce paramètre est en pages, pas en octets, donc copier la même valeur à partir de net.ipv4.tcp_rmem ou net.ipv4.tcp_wmem (les deux en octets) n'a aucun sens. Il est réglé automatiquement par Linux en fonction de votre quantité de mémoire, il a donc rarement besoin d'être ajusté. En fait, cela peut être votre problème, limitant arbitrairement la mémoire disponible pour la mise en file d'attente de connexion globale.

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

Notez également que votre "vm.swappiness = 0" est défini deux fois, une fois sur 10 et à nouveau en bas sur 0, qui est la valeur effective.

Sur le serveur Varnish, essayez de modifier ces 2 paramètres:

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

tw_reuse lui permettra de réutiliser les connexions dans TIME_WAIT.

tw_recycle pourrait provoquer des problèmes avec les équilibreurs de charge, etc.