大量のTIME_WAIT接続でnetstatが表示される

さて、これは私を忍び寄っています-私はこれらの約1500-2500を見ます：

root@wherever:# netstat

Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 localhost:60930         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60934         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60941         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60947         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60962         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60969         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60998         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60802         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60823         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60876         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60886         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60898         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60897         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60905         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60918         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60921         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60673         localhost:sunrpc        TIME_WAIT  
tcp        0      0 localhost:60680         localhost:sunrpc        TIME_WAIT  
[etc...]

root@wherever:# netstat | grep 'TIME_WAIT' |wc -l
1942

その数は急速に変化しています。

私はかなりタイトなiptables設定を持っているので、何がこれを引き起こす可能性があるのか​​分かりません。何か案は？

おかげで、

タマス

編集： 'netstat -anp'の出力：

Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:60968         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60972         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60976         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60981         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60980         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60983         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60999         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60809         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60834         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60872         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60896         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60919         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60710         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60745         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60765         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60772         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60558         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60564         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60600         127.0.0.1:111           TIME_WAIT   -               
tcp        0      0 127.0.0.1:60624         127.0.0.1:111           TIME_WAIT   -               

編集： tcp_fin_timeout はTIME_WAIT期間を制御しません、それは60 秒でハードコードされています

他の人が述べたように、いくつかの接続がTIME_WAIT存在することは、TCP接続の通常の部分です。間隔を確認するには、次を調べ/proc/sys/net/ipv4/tcp_fin_timeoutます。

[root@host ~]# cat /proc/sys/net/ipv4/tcp_fin_timeout
60

そして、その値を変更して変更します：

[root@dev admin]# echo 30 > /proc/sys/net/ipv4/tcp_fin_timeout

または永続的に/etc/sysctl.confに追加して

net.ipv4.tcp_fin_timeout=30

また、RPCサービスまたはNFSを使用しない場合は、単に無効にすることができます。

/etc/init.d/nfsd stop

そして、完全にオフにします

chkconfig nfsd off

TIME_WAITは正常です。これは、ソケットが閉じた後の状態であり、紛失してパーティーに遅れたパケットを追跡するためにカーネルによって使用されます。多数のTIME_WAIT接続は、短時間の接続が大量に発生することを示す症状であり、心配する必要はありません。

重要ではありません。意味するのは、多くのSun RCP TCP接続（2〜4分ごとに1500〜2500）を開いたり閉じたりすることだけです。のTIME_WAITこれらはソケットがあまりにも早く再利用、および他の有用な目的のカップルのためにされた可能性がある場合のような状態が間違っているアプリケーションのために到着からメッセージを防ぐために、ソケットは、それが閉じたときに何が起こっています。心配しないでください。

（もちろん、実際にはそれほど多くのRCP操作を処理するものを実行していない場合を除きます。その後、心配してください。）

システム上の何かが、システム内で多くのRPC（リモートプロシージャコール）を実行しています（ソースと宛先の両方がlocalhostであることに注意してください）。NFSマウントのlockdでよく見られますが、rpc.statdやrpc.sprayなどの他のRPC呼び出しでも見られることがあります。

「lsof -i」を使用して、これらのソケットを開いているユーザーを確認し、何が実行されているかを確認できます。おそらく無害です。

tcp_fin_timeoutTIME_WAIT遅延を制御しません。これを確認するには、ssまたはnetstatに-oを付けてカウントダウンタイマーを表示します。

cat /proc/sys/net/ipv4/tcp_fin_timeout
3

# See countdown timer for all TIME_WAIT sockets in 192.168.0.0-255
ss --numeric -o state time-wait dst 192.168.0.0/24

NetidRecv-Q  Send-Q    Local Address:Port    Peer Address:Port                             
tcp  0       0         192.168.100.1:57516   192.168.0.10:80    timer:(timewait,55sec,0)   
tcp  0       0         192.168.100.1:57356   192.168.0.10:80    timer:(timewait,25sec,0)   
tcp  0       0         192.168.100.1:57334   192.168.0.10:80    timer:(timewait,22sec,0)   
tcp  0       0         192.168.100.1:57282   192.168.0.10:80    timer:(timewait,12sec,0)   
tcp  0       0         192.168.100.1:57418   192.168.0.10:80    timer:(timewait,38sec,0)   
tcp  0       0         192.168.100.1:57458   192.168.0.10:80    timer:(timewait,46sec,0)   
tcp  0       0         192.168.100.1:57252   192.168.0.10:80    timer:(timewait,7.436ms,0) 
tcp  0       0         192.168.100.1:57244   192.168.0.10:80    timer:(timewait,6.536ms,0)

tcp_fin_timeoutが3に設定されていても、TIME_WAITのカウントダウンは60から開始されます。ただし、net.ipv4.tcp_tw_reuseが1（echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse）に設定されている場合、カーネルはTCPで競合が発生しないと判断した場合、TIME_WAITでソケットを再利用できますセグメント番号。

私も同じ問題を抱えていました。何が起こっているのかを知るのに数時間かかりました。私の場合、この理由は、netstatがIPに対応するホスト名を検索しようとするためです（gethostbyaddr APIを使用していると仮定します）。/etc/nsswitch.confのない組み込みLinuxインストールを使用していました。驚いたことに、この問題は、実際にnetstat -aを実行している場合にのみ存在します（詳細モードおよびデバッグモードでportmapを実行することで確認できます）。

次に、次のことが行われました。デフォルトでは、ルックアップ関数はypbindデーモン（Sun Yellow Pages、NISとも呼ばれる）に接続してホスト名を照会しようとします。このサービスを照会するには、ポートマッパーportmapに接続して、このサービスのポートを取得する必要があります。これで、私の場合のポートマッパーはTCP経由で接続されました。次に、ポートマッパーはlibc関数に、そのようなサービスが存在せず、TCP接続が閉じられることを伝えます。知っているように、閉じられたTCP接続はしばらくの間TIME_WAIT状態に入ります。したがって、netstatは一覧表示時にこの接続をキャッチし、新しいIPを持つこの新しい行は、TIME_WAIT状態などで新しい接続を生成する新しい要求を発行します...

この問題を解決するには、RPC NISサービスを使用していない/etc/nsswitch.confを作成します。つまり、次の内容を使用します。

passwd:         files
group:          files
hosts:          files dns
networks:       files dns
services:       files
protocols:      files
netmasks:       files