Lösung 1:
Das Problem könnte sein, dass Sie zu viele Interrupts auf Ihrer Netzwerkkarte erhalten. Wenn die Bandbreite nicht das Problem ist, ist die Frequenz das Problem:
-
Sende-/Empfangspuffer auf der Netzwerkkarte aufdrehen
ethtool -g eth0
Zeigt Ihnen die aktuellen Einstellungen (256 oder 512 Einträge). Sie können diese wahrscheinlich auf 1024, 2048 oder 3172 erhöhen. Mehr macht wahrscheinlich keinen Sinn. Dies ist nur ein Ringpuffer, der sich nur füllt, wenn der Server eingehende Pakete nicht schnell genug verarbeiten kann.
Wenn sich der Puffer zu füllen beginnt, ist die Flusskontrolle ein zusätzliches Mittel, um dem Router oder Switch mitzuteilen, dass er langsamer werden soll:
-
Schalten Sie die ein-/ausgehende Flusskontrolle auf dem Server und den Switch-/Router-Ports ein, an die er angeschlossen ist.
ethtool -a eth0
Wird wahrscheinlich zeigen:
Pause parameters for eth0:
Autonegotiate: on
RX: on
TX: on
Überprüfen Sie /var/log/messages auf die aktuelle Einstellung von eth0. Suchen Sie nach etwas wie:
eth0:Link ist bei 1000 Mbps, Vollduplex, Flusskontrolle tx und rx
Wenn Sie tx und rx nicht sehen, müssen Ihre Netzwerkadministratoren die Werte auf dem Switch/Router anpassen. Bei Cisco ist die Empfangs-/Sendeflusskontrolle aktiviert.
Achtung: Wenn Sie diese Werte ändern, wird Ihr Link für sehr kurze Zeit (weniger als 1 Sekunde) herunter- und wieder hochgefahren.
-
Wenn das alles nicht hilft - Sie können auch die Geschwindigkeit der Netzwerkkarte auf 100 MBit reduzieren (dasselbe an den Switch/Router-Ports tun)
ethtool -s eth0 autoneg off && ethtool -s eth0 speed 100
Aber in Ihrem Fall würde ich sagen - erhöhen Sie die Empfangspuffer im NIC-Ringpuffer.
Lösung 2:
Das Folgende ist vielleicht nicht die endgültige Antwort, aber es wird definitiv einige Ideen hervorbringen
Versuchen Sie, diese zu sysctl.conf hinzuzufügen
## tcp selective acknowledgements.
net.ipv4.tcp_sack = 1
##enable window scaling
net.ipv4.tcp_window_scaling = 1
##
net.ipv4.tcp_no_metrics_save = 1
Während selektive TCP-Pakete für eine optimale Leistung im Fall von Netzwerken mit hoher Bandbreite gut sind. Aber Vorsicht vor anderen Nachteilen. Die Vorteile der Fensterskalierung werden hier beschrieben. Zur dritten sysctl-Option:Standardmäßig speichert TCP verschiedene Verbindungsmetriken im Route-Cache, wenn die Verbindung geschlossen wird, damit Verbindungen, die in naher Zukunft hergestellt werden, diese verwenden können, um Anfangsbedingungen festzulegen. Normalerweise erhöht dies die Gesamtleistung, kann aber manchmal zu Leistungseinbußen führen. Wenn gesetzt, speichert TCP keine Metriken beim Schließen von Verbindungen.
Prüfen Sie mit
ethtool -k ethX
um zu sehen, ob das Offloading aktiviert ist oder nicht. TCP-Prüfsummen-Offload und Large-Segment-Offload werden von den meisten heutigen Ethernet-NICs unterstützt, und anscheinend unterstützt Broadcom dies auch.
Versuchen Sie es mit dem Tool
powertop
während das Netzwerk im Leerlauf ist und wenn die Netzwerksättigung erreicht ist. Dies wird definitiv zeigen, ob NIC-Interrupts der Schuldige sind. Die Geräteabfrage ist eine Antwort auf eine solche Situation. FreeBsd unterstützt Polling Switch direkt in ifconfig, aber Linux hat keine solche Option. Konsultieren Sie dies, um die Abfrage zu aktivieren. Es heißt, dass BroadCom auch Umfragen unterstützt, was eine gute Nachricht für Sie ist.
Jumbo Packet Tweak ist möglicherweise nicht für Sie geeignet, da Sie erwähnt haben, dass Ihr Datenverkehr hauptsächlich aus kleinen Paketen besteht. Aber probier es doch mal aus !
Lösung 3:
Ich habe in der Liste der Tweaks bemerkt, dass Zeitstempel deaktiviert sind, bitte tun Sie das nicht. Das ist ein alter Rückblick auf vergangene Tage, als Bandbreite wirklich teuer war und die Leute ein paar Bytes/Paket sparen wollten. Es wird heutzutage beispielsweise vom TCP-Stack verwendet, um festzustellen, ob ein Paket, das für einen Socket in "CLOSE_WAIT" ankommt, ein altes Paket für die Verbindung oder ein neues Paket für eine neue Verbindung ist, und hilft bei RTT-Berechnungen. Und das Speichern der wenigen Bytes für einen Zeitstempel ist NICHTS im Vergleich zu dem, was IPv6-Adressen hinzufügen werden. Das Deaktivieren von Zeitstempeln schadet mehr als es nützt.
Diese Empfehlung zum Deaktivieren von Zeitstempeln ist nur ein Rückschlag, der immer wieder von einer Generation von Systemadministratoren an die nächste weitergegeben wird. Eine Art "Urban Legend".
Lösung 4:
Sie müssen die Last auf alle CPU-Kerne verteilen. Starten Sie 'irqbalance'.
Lösung 5:
In meinem Fall nur eine einzige Stimmung:
net.ipv4.tcp_timestamps = 0
eine sehr große und nützliche Änderung vorgenommen, die Ladezeit der Website um 50 % verringert.