web-dev-qa-db-ja.com

さまざまなプロセスのCLOSE_WAITでの非クローズTCP接続

Debian 6.0で実行されている10GBEネットワーク（NICはIntel 82599EB 10GBE SFI/SFP +）に接続された複数のマシンのクラスターがあり、CLOSE_WAIT状態での接続の切断TCP接続）の問題に直面しています。 CLOSE_WAIT状態の理論接続は、アプリケーションによって明示的に閉じる必要がありますが、私の場合、少なくとも2つの異なるアプリケーションがこれらのハングした接続を生成し、問題は別のものにあると思います。

最初、この問題はCassandra 'jsvc'プロセスでデーモンとして実行されています。Cassandra（ "server"）の1つのノードが接続を閉じませんでしたこの接続を開始した別のノード（「クライアント」）の片側が閉じられました。その後、「netperf」TCP_CRRテストを実行し、エラーメッセージが表示されました。

netperf -H 172.15.2.166 -t TCP_CRR -l -5 -D TCP接続/要求/応答テスト0.0.0.0（0.0.0.0）ポート0 AF_INETから172.15.2.166（172.15。 2.166）ポート0 AF_INET：デモsend_tcp_conn_rr：データ受信エラー：ピアによって接続がリセットされました

Recv-Qに奇妙な1バイトがある172.15.2.166マシンでTCP接続がCLOSE_WAIT状態でハングしている。

tcp 1 0 172.15.2.166:12865 172.15.2.161:42863 CLOSE_WAIT

'ixgbe'ドライバーを最新の3.9-NAPIに更新しましたが、この問題は引き続き発生し、他に何が問題を引き起こす可能性があるのでしょうか。

tcpconnectioncassandra
3
anglerhood
  1. あなたのメモは、サーバーがクライアントからFINに続いてRSTを見たことを示しています
    そして、おそらく、サーバーアプリが適切に閉じられていません
  2. 何らかの理由で、接続がどのアプリケーションに属しているかわからない場合は、
    使用する lsof -n | grep CLOSE.WAIT
  3. これがCassendraの場合は、確認することをお勧めします
    このStackOverflowの質問、 cassandraの開いているファイルが多すぎます
2
nik