Der Lack hat keine offenen Ports mehr, viele SYN_SENT-Verbindungen

Vor kurzem sind Probleme mit unserem Setup für Lack (3x) -> Apache (3x) aufgetreten, was zu einem enormen Anstieg der SYN_SENTVerbindungen geführt hat.

Die Spitze selbst ist auf die Menge an neuem Datenverkehr zurückzuführen, der auf die Site trifft (kein DDOS jeglicher Art), und es scheint, dass unsere Lackmaschinen Probleme haben, Datenverkehr an die Back-End-Server weiterzuleiten (ein Rückgang des Apache-Datenverkehrs korreliert mit Spitzen auf den Lacken ), Überlastung des Pools der verfügbaren Ports mit SYN_SENT.

Keep-Alives sind in Apache (15s) aktiviert.

Auf welcher Seite liegt der Fehler? Das Verkehrsaufkommen ist erheblich, sollte jedoch keinesfalls dazu führen, dass ein solches Setup (3x Lack-Frontend-Computer, 3x Backend-Apache-Server) zum Stillstand kommt.

Bitte helfen Sie.

Munin Screenshot für Verbindungen durch Firewall ist hier .

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

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

Ihr Problem liegt wahrscheinlich mit dem sysctl auf den Apache-Servern.

Einige Annahmen: Normalerweise verarbeitet Varnish jede Verbindung erheblich schneller als ein Webserver (es sei denn, Ihre Varnish-Server haben möglicherweise viel weniger CPU und Ihre Apache-Server stellen nur statische Dateien bereit, die im Speicher zwischengespeichert sind.) Ich gehe davon aus, dass Ihre Verbindungen schneller verarbeitet werden in Lack als Apache.

Daher sind die Ressourcen auf Ihren Apache-Servern möglicherweise ausreichend, aber Anforderungen müssen irgendwo in der Warteschlange stehen, wenn auch nur sehr kurz. Im Moment stehen sie nicht auf gesunde Weise an, wo sie schließlich verarbeitet werden.

Es scheint, als ob Ihre Anfragen in Varnish stecken bleiben und es nicht zu den Apache-Servern schaffen.

Dafür gibt es einige Hinweise:

Beachten Sie in Ihrem Munin-Diagramm, dass die Anforderungen in TIME_WAIT zunehmen, bevor die SYN_SENTs gesichert werden. Nach einem bestimmten Punkt häufen sie sich als SYN_SENTS. Dies zeigt an, dass Anfragen langsamer beantwortet werden, die Warteschlange dann gesichert wird und Anfragen überhaupt nicht beantwortet werden.

Dies zeigt mir an, dass Ihr Apache-Server nicht genügend Verbindungen akzeptiert (wo sie sich dann anstellen können, damit Apache sie verarbeiten kann).

Ich sehe mehrere mögliche Grenzen in Ihrer Konfigurationsdatei:

Wenn Sie eine Spitze haben, haben Sie ungefähr 30000 Verbindungen im Status SYN_SENT auf Ihrem Lackserver.

Auf dem Apache-Server ist Ihr max_syn_backlog jedoch nur 16384. Ihr somaxconn ist nur 2048.

Beachten Sie auch, dass die Größe Ihrer Netzwerkspeicherpuffer auf den Apache-Servern sehr gering ist. Sie haben sie auf dem Lackserver auf 16 MB eingestellt. Auf dem Apache-Server beträgt Ihre net.ipv4.tcp_rmem jedoch nur 524 KB, um mit Ihrer net.core.rmem_max übereinzustimmen.

Ich empfehle, alle diese Parameter auf dem Apache-Server zu erhöhen.

Sie müssen sich mehr auf die Diagnose auf dem Apache-Server konzentrieren, um genau herauszufinden, was gerade passiert. Möglicherweise müssen Sie dies jedoch nicht tun, wenn Sie diese Werte erhöhen.

Sie sollten net.ipv4.tcp_mem wahrscheinlich nicht anpassen. Beachten Sie, dass die Einheit für diesen Parameter in Seiten und nicht in Bytes angegeben ist. Daher macht das Kopieren des gleichen Werts aus net.ipv4.tcp_rmem oder net.ipv4.tcp_wmem (beide in Bytes) keinen Sinn. Es wird von Linux basierend auf Ihrer Speichermenge automatisch optimiert, sodass es nur selten angepasst werden muss. Tatsächlich kann dies Ihr Problem sein, indem Sie den für die gesamte Verbindungswarteschlange verfügbaren Speicher willkürlich einschränken.

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

Beachten Sie auch, dass Ihre "vm.swappiness = 0" zweimal gesetzt wird, einmal als 10 und erneut unten als 0, was der effektive Wert ist.

Versuchen Sie auf dem Lackserver, diese beiden Parameter zu ändern:

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

Mit tw_reuse können die Verbindungen in TIME_WAIT wiederverwendet werden.

tw_recycle kann Probleme mit Load Balancern usw. verursachen.