web-dev-qa-db-ja.com

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

Ubuntu Server 10.04.1 x86

Nginxの背後にあるFCGI HTTPサービスを備えたマシンを持っています。これは、多数の小さなクライアントに多数の小さなHTTPリクエストを提供します。 （ピーク時に毎秒約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つ目のワーカーをすぐに追加する予定です。その場合、ドメインソケットを使用できません。

ubuntunginxlinux-networkinghigh-load
36
Alexander Gladysh

最初にすべきことは、net.ipv4.tcp_fin_timeout=1を修正することです。それは安値への道です、あなたはおそらくそれよりもはるかに低い30を取るべきではありません。

これはnginxの背後にあるため。それはnginxがリバースプロキシとして機能していることを意味しますか？その場合、接続は2倍になります（1つはクライアント、もう1つは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は、この link で暗示されています。

また、/ proc/sys/net/ipv4/tcp_max_tw_bucketsは混乱を招きます。デフォルトは180000に設定されていますが、最大twバケットに関係なく、システムに32K TIME_WAITソケットがあると、TCPの混乱が発生します。

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

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

再利用対リサイクル：
これらは一種の興味深いもので、reuseはtime_Waitソケットの再利用を可能にするように読み取られ、リサイクルはそれを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 clientsで問題が発生するためです。

両方をオンにしないでみて、どのような効果があるか確認してください（一度に1つずつ試して、それぞれの動作を確認してください）。 Muninよりも速いフィードバックにはnetstat -n | grep TIME_WAIT | wc -lを使用します。

29
Kyle Brandt

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

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

2
andrew pate