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、サービスの問題を隠すために高い値を使用するため、ユーザーの観点から見ると、接続の中断/タイムアウト（net.ipv4.tcp_abort_on_overflowLinuxで制御）ではなく、待ち時間のスパイクのように見えます。

listen(2)マニュアルによると- net.core.somaxconn小さいものを自由に選択できるアプリケーション（通常はアプリの構成で設定されます）の上限のみになります。一部のアプリは単に使用listen(fd, -1)するため、システムで許可されている最大値にバックログを設定します。

本当の原因のいずれか低い処理率（例えばAシングルスレッドのブロッキング・サーバ）やワーカースレッド/プロセスの数が不十分（例えば、マルチプロセス/のようなソフトウェアをブロックしているスレッドapache/ tomcat）

PS。ユーザーを待たせるよりも、高速で失敗してロードバランサーにジョブを実行（再試行）させることが望ましい場合があります。そのためにnet.core.somaxconn、値を設定し、アプリケーションバックログを例えば1に10設定net.ipv4.tcp_abort_on_overflowします。

PPS。古いバージョンのLinuxカーネルには、somaxcon値を16の下位ビットに切り捨てる（つまりuint16_t、値をにキャストする）厄介なバグがあるため、その値を65535危険な値以上に上げることがあります。詳細については、http：//patchwork.ozlabs.org/patch/255460/を参照してください。

Linuxのすべてのバックログ内部について詳しく知りたい場合は、お読みください： LinuxでのTCPバックログの仕組み。