it-swarm.com.de

Wird eine Erhöhung von net.core.somaxconn einen Unterschied machen?

Ich bin auf ein Argument für den Parameter net.core.somaxconn gestoßen: Mir wurde gesagt, dass es keinen Unterschied macht, wenn wir den Standardwert 128 ändern.

Ich glaubte, dies könnte ein ausreichender Beweis sein:

"Wenn das Backlog-Argument größer als der Wert in/proc/sys/net/core/somaxconn ist, wird es stillschweigend auf diesen Wert abgeschnitten" http://linux.die.net/man/2/listen

aber es ist nicht.

Kennt jemand eine Methode, um dies mit zwei Maschinen zu bezeugen, die in einem Gbit-Netzwerk sitzen? Das Beste wäre gegen MySQL, LVS, Apache2 (2.2), memcached.

31
petermolnar

Das Setzen von net.core.somaxconn Auf höhere Werte ist nur auf hochgeladenen Servern erforderlich, auf denen die neue Verbindungsrate so hoch/platzt, dass 128 (50% mehr in BSDs: 128 backlog + 64 half-open ) noch nicht akzeptierte Verbindungen gelten als normal. Oder wenn Sie die Definition von "normal" an eine Anwendung selbst delegieren müssen.

Einige Administratoren verwenden high net.core.somaxconn, Um Probleme mit ihren Diensten zu verbergen. Aus Sicht des Benutzers sieht es also wie eine Latenzspitze aus, anstatt wie eine Verbindung unterbrochen/Zeitüberschreitung (gesteuert durch net.ipv4.tcp_abort_on_overflow Unter Linux). .

listen(2) manual sagt - net.core.somaxconn fungiert nur als obere Grenze für eine Anwendung, die frei ist, etwas Kleineres zu wählen (normalerweise in der Konfiguration der App festgelegt). Obwohl einige Apps nur listen(fd, -1) verwenden, bedeutet dies, dass der Rückstand auf den vom System zulässigen Maximalwert gesetzt wird.

Die eigentliche Ursache ist entweder eine niedrige Verarbeitungsrate (z. B. ein Blockierungsserver mit einem Thread) oder eine unzureichende Anzahl von Arbeitsthreads/-prozessen (z. B. Blockierungssoftware für mehrere Prozesse/Threads wie Apache/Tomcat).

PS. Manchmal ist es vorzuziehen, schnell zu versagen und den Load-Balancer seine Arbeit erledigen zu lassen (erneut versuchen), als den Benutzer warten zu lassen. Zu diesem Zweck setzen wir net.core.somaxconn Auf einen beliebigen Wert und begrenzen den Anwendungsstau auf z. 10 Und setzen Sie net.ipv4.tcp_abort_on_overflow Auf 1.

PPS. Alte Versionen des Linux-Kernels haben den bösen Fehler, den Wert von somaxcon auf 16 niedrigere Bits zu kürzen (dh den Wert auf uint16_t Zu setzen), sodass dieser Wert auf mehr als 65535 Erhöht werden kann sei gefährlich. Weitere Informationen finden Sie unter: http://patchwork.ozlabs.org/patch/255460/

Wenn Sie mehr über alle Backlog-Interna in Linux erfahren möchten, lesen Sie bitte: Wie TCP Backlog funktioniert unter Linux .

48
SaveTheRbtz