TIME_WAITでソケットの数を減らす方法は？

Ubuntu Server 10.04.1 x86

nginxの背後にFCGI HTTPサービスを備えたマシンがあります。これは、多くの異なるクライアントに多くの小さなHTTPリクエストを処理します。（ピーク時の1秒あたり約230リクエスト、ヘッダー付きの平均応答サイズは650バイト、1日あたり数百万の異なるクライアントです。）

その結果、TIME_WAITでハングする多くのソケットがあります（以下のTCP設定でグラフがキャプチャされます）。

TIME_WAIT

ソケットの数を減らしたい。

これ以外に何ができますか？

$ cat / proc / sys / net / ipv4 / tcp_fin_timeout
1
$ cat / proc / sys / net / ipv4 / tcp_tw_recycle
1
$ cat / proc / sys / net / ipv4 / tcp_tw_reuse
1

更新：マシン上の実際のサービスレイアウトに関する詳細：

クライアント----- TCP-socket-> nginx（ロードバランサーリバースプロキシ） 
       ----- TCP-socket-> nginx（ワーカー） 
       --domain-socket-> fcgi-software
                          --single-persistent-TCP-socket-> Redis
                          --single-persistent-TCP-socket-> MySQL（他のマシン）

ロードバランサー->ワーカー接続もドメインソケットに切り替える必要がありますが、TIME_WAITソケットに関する問題は残ります。すぐに別のマシンに2番目のワーカーを追加する予定です。その場合、ドメインソケットを使用することはできません。

— アレクサンダー・グラディス
ソース

ムニンは恥知らずに嘘をついているようです。カイルの答えへのコメントをご覧ください。今それを調べています。

— アレクサンダーグラディシュ

：Muninのについての質問を作成しserverfault.com/questions/212200/...

— アレクサンダーGladysh

今では...そのMuninのは嘘ではない、むしろ私が間違ってプロットを見てるように見えます

— アレクサンダーGladysh

回答:

開始するためにすべきことの1つは、を修正することnet.ipv4.tcp_fin_timeout=1です。それは低値への道であり、おそらく30よりもずっと低く取るべきではありません。

これはnginxの背後にあるためです。それはnginxがリバースプロキシとして機能しているということですか？その場合、接続は2倍になります（クライアントへの接続、Webサーバーへの接続）。これらのソケットがどちらの端に属しているか知っていますか？

更新：
fin_timeoutは、FIN-WAIT-2にとどまる時間です（networking/ip-sysctl.txtカーネルのドキュメントから）。

tcp_fin_timeout - INTEGER
        Time to hold socket in state FIN-WAIT-2, if it was closed
        by our side. Peer can be broken and never close its side,
        or even died unexpectedly. Default value is 60sec.
        Usual value used in 2.2 was 180 seconds, you may restore
        it, but remember that if your machine is even underloaded WEB server,
        you risk to overflow memory with kilotons of dead sockets,
        FIN-WAIT-2 sockets are less dangerous than FIN-WAIT-1,
        because they eat maximum 1.5K of memory, but they tend
        to live longer. Cf. tcp_max_orphans.

LinuxでTIME_WAITソケット番号を32kの上限のように維持する必要があるのではないかと思います。これがLinuxがそれらをリサイクルする場所です。この32kはこのリンクで暗示されています：

また、/ proc / sys / net / ipv4 / tcp_max_tw_bucketsは紛らわしいです。デフォルトは180000に設定されていますが、最大twバケットに関係なく、システムに32KのTIME_WAITソケットがあるとTCPが中断します。

このリンクは、TIME_WAIT状態が60秒であり、procを介して調整できないことも示唆しています。

ランダムな楽しい事実：
各ソケットのnetstatでtimewaitのタイマーを見ることができますnetstat -on | grep TIME_WAIT | less

再利用とリサイクル：
これらは興味深いものです。再利用のように見え、time_Waitソケットの再利用を有効にし、recycleはそれをTURBOモードにします：

tcp_tw_recycle - BOOLEAN
        Enable fast recycling TIME-WAIT sockets. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

tcp_tw_reuse - BOOLEAN
        Allow to reuse TIME-WAIT sockets for new connections when it is
        safe from protocol viewpoint. Default value is 0.
        It should not be changed without advice/request of technical
        experts.

net.ipv4.tcp_tw_recycleを使用すると、NATクライアントで問題が発生するため、使用しないことをお勧めします。

両方のスイッチをオンにせずに、その効果を確認してみてください（一度に1つずつ試して、それぞれの動作を確認してください）。netstat -n | grep TIME_WAIT | wc -lMuninよりも高速なフィードバックに使用します。

— カイル・ブラント
ソース

@Kyle：どんな価値net.ipv4.tcp_fin_timeoutがありますか？

— アレクサンダーグラディシュ

@Kyle：クライアント--TCP-socket-> nginx（ロードバランサーリバースプロキシ）--TCP-socket-> nginx（ワーカー）--domain-socket-> fcgi-software

— Alexander Gladysh

と言う30か、多分20。試してみてください。負荷が大きいため、多くのTIME_WAITの種類が理にかなっています。

— カイルブラント

@Kyle：愚かな質問には申し訳ありません（私は残念ながら、これまでのところ、ここで貨物カルトレベルでだ）、しかし、私は私が変更されたときに見て正確に何を期待するべきであるnet.ipv4.tcp_fin_timeoutから1に20？

— アレクサンダーグラディシュ

ああ、ここにいいライナーがあります：netstat -an|awk '/tcp/ {print $6}'|sort|uniq -c。したがって、@ Alexは、Muninが気に入らない場合、これらの統計を監視する方法にドリルダウンする可能性があります。たぶん、唯一の問題は、Muninがあなたに悪いデータを与えていることです：

— カイル・ブラント

tcp_tw_reuseは、TIME_WAIT接続を再利用できるため、比較的安全です。

また、ポートの不足が問題になる場合は、ロードバランサーの背後の異なるポートでリッスンするサービスをさらに実行できます。

— アンドリュー・パテ
ソース