TIME_WAIT（実際にはその多く）が私たちのサーバーの1つの速度低下の実際の原因であるという確かな証拠が必要です。サーバーは Parallels Baremetal 仮想化でホストされ、物理サーバーはデュアル CPU と 2 GB RAM を搭載した CentOS5 という仮想マシンです。
1週間前から、私たちは遅すぎて、いくつかのファイル（約20個）しかないディレクトリで "ls"を実行しても結果を表示するのに約1.5秒かかることに気づき始めました。
私はこれを試しましたが、vmstatそれを使用するスワップがないようです。ネットワークにボトルネックがありません。ただし、実行すると、topJavaが主にリソースを消費していることがわかります。 VMがハドソンサーバーであるため、Javaが必要です。
私の同僚の一人が以下を介して接続を確認しようとしました。
$ vmstat -vatpno
そして、TIME_WAIT状態に約300以上の接続がたくさんあることを確認しました。だから我々はこれらの提案のいくつかを適用しようとします。このページ具体的には、TCP_FIN_TIMEOUT、TCP_KEEPALIVE_INTERVAL、およびTCP_KEEPALIVE_PROBESです。 TIME_WAITの接続数が減少しましたが、それでも220から280の間で変動します（おそらくTIME_WAITの他の接続はまだ「タイムアウト」していないが、時々新しい接続が追加されたため）。後で改善が見られない場合は、TCP_TW_RECYCLEとTCP_TW_REUSEを追加してみてください。
それでは、主な質問に戻ります。複数のTIME_WAIT接続が多くのRAMを消費するという確かな証拠はありますか？
ベストアンサー1
TIME_WAIT状態の接続は、他の接続のパケットと混在しないように、もう一方の端でネットワークを介して着信した最後の迷子になったパケットがあるかどうかを確認するために単に待っています。実際にはありませんするこのパケットに関連するすべて。したがって、TIME_WAIT 接続はオープン接続よりも少ないリソースを使用します。
今日のよく構成されたWebサーバー10,000以上の同時接続を処理できます。（この記事は2003年に書かれており、ムーアの法則は進化し続けています。）とにかく、TIME_WAIT状態の接続は開いている接続より少ないメモリを占有するため、TIME_WAIT状態の300個の接続は何もありません。
TIME_WAITの詳細については、次を参照してください。http://tangentsoft.net/wskfaq/articles/debugging-tcp.htmlそしてhttp://developerweb.net/viewtopic.php?id=2941。
また、あなたのディスクI / Oの使用量がどんなものか知りたいです。私の経験によると、過度のディスクI / Oは、過剰なCPU使用率よりもLinuxカーネルの速度をより簡単に低下させます。彼らが何を言っているのかを調べるには、調査iostatとツールが必要な場合があります。dstat