net.core.somaxconnを増やすと違いが生じますか？
Net.core.somaxconnパラメータの引数に触れました。デフォルトの128を変更しても、違いはないと言われました。
私はこれで十分な証拠かもしれないと信じていました：
「バックログ引数が/ proc/sys/net/core/somaxconnの値よりも大きい場合、その値に暗黙的に切り捨てられます」 http://linux.die.net/man/2/listen
しかし、そうではありません。
Gbitネットワーク上にある2台のマシンでこれを証明する方法を知っている人はいますか？ MySQL、LVS、Apache2（2.2）、memcachedが最適です。
_net.core.somaxconn_を高い値に設定する必要があるのは、新しい接続率が非常に高い/バースト性が高く、128（BSDでは50％多い：128 backlog + 64 _half-open_）ではない高負荷のサーバーのみです。 -まだ受け入れられている接続は正常と見なされます。または、「通常」の定義をアプリケーション自体に委任する必要がある場合。
一部の管理者はサービスの問題を隠すために高い_net.core.somaxconn_を使用しているため、ユーザーの観点から見ると、接続が中断された/タイムアウト（Linuxでは_net.ipv4.tcp_abort_on_overflow_によって制御される）ではなく、待ち時間のスパイクのように見えます。
listen(2)マニュアルによると、_net.core.somaxconn_は、小さいものを選択するのが自由なアプリケーション（通常は、アプリケーションの構成で設定）の上限のみとして機能します。一部のアプリはlisten(fd, -1)を使用しますが、これはバックログをシステムで許可されている最大値に設定することを意味します。
実際の原因は、処理速度が低い（シングルスレッドのブロッキングサーバーなど）か、ワーカースレッド/プロセスの数が不十分（マルチプロセス/ Apache/Tomcatなどのスレッドブロッキングソフトウェア）のいずれかです。
PS。場合によっては、ユーザーを待機させるよりも、すばやく失敗してロードバランサーにその仕事（再試行）をさせるほうが望ましい場合があります。そのため、_net.core.somaxconn_に任意の値を設定し、アプリケーションバックログを次のように制限します。 _10_および_net.ipv4.tcp_abort_on_overflow_を1に設定します。
PPS。 Linuxカーネルの古いバージョンには、somaxconの値を下位16ビットに切り詰めるという厄介なバグがあります（つまり、値を_uint16_t_にキャストします）。そのため、その値を_65535_よりも大きくすると危険です。 。詳細については、次を参照してください： http://patchwork.ozlabs.org/patch/255460/
Linuxのすべてのバックログ内部についてさらに詳しく知りたい場合は、自由に読んでください： How TCP backlog works in Linux 。