Linux チュートリアル: Nginx の同時接続数と接続ステータスのクエリ

Linux上での同時接続数やNginx等の接続状況を表示します。

1. Web サーバー (Nginx Apache) の同時リクエスト数とその TCP 接続ステータスを確認します。

netstat -n awk '/^tcp/ {++S[$NF]} END {for(a) S で) print a, S[a]}'

または:

netstat -n awk '/^tcp/ {++state[$NF]} END {for(状態のキー) print key,"t ",state [key]}'返される結果は通常次のとおりです:

LAST_ACK 5 (処理待ちのリクエスト数)

SYN_RECV 30

ESTABLISHED 1597 (通常のデータ送信ステータス)

FIN_WAIT1 51

FIN_WAIT2 504

TIME_ WAIT 1057 (処理完了、タイムアウトの終了を待機しているリクエストの数)

その他のパラメーターの説明:

CLOSED: アクティブまたは進行中の接続はありません

LISTEN: サーバーは着信呼び出しを待機しています

SYN_RECV: 接続リクエストが到着し、確認を待っています

SYN_SENT: アプリケーションが開始され、接続をオープンしています

ESTABLISHED: 通常のデータ転送ステータス

FIN_WAIT1: アプリケーションは完了したと言っています

FIN_WAIT2: 相手側はリリースに同意しました

ITMED_WAIT: すべてのパケットが消滅するのを待っています

CLOSING: 両側同時にクローズを試行します

TIME_WAIT: 相手側がリリースを初期化しました

LAST_ACK: すべてのパケットが消滅するのを待ちます

一般的に使用される 3 つ状態は次のとおりです。ESTABLISHED は通信中、TIME_WAIT はアクティブなクローズ、CLOSE_WAIT はパッシブなクローズを意味します。

TCP プロトコルでは、確立された接続について、正常に切断するにはネットワーク上の双方が 4 ウェイ ハンドシェイクを実行する必要があると規定しています。これらの手順のいずれかが欠けている場合、接続は一時停止アニメーション状態になり、リソースが占有されます。接続自体では解放されません。ネットワーク サーバー プログラムは同時に多数の接続を管理する必要があるため、無駄な接続が完全に切断されていることを確認する必要があります。そうしないと、大量の切断された接続が大量のサーバー リソースを浪費します。多くの TCP 状態の中で、CLOSE_WAIT と TIME_WAIT という 2 つの最も注目すべき状態があります。

TIME_WAIT

TIME_WAIT は、リンクがアクティブに閉じられ、2MSL 時間、約 4 分間待機すると形成されます。主に最後の ACK が失われるのを防ぐためです。 TIME_WAIT には非常に長い時間がかかるため、サーバーは閉じられるアクティブな接続の数を最小限に抑えるように努める必要があります。

CLOSE_WAIT

CLOSE_WAIT は、接続を受動的に閉じることによって形成されます。 TCP ステート マシンによれば、サーバーはクライアントから送信された FIN を受信すると、TCP 実装に従って ACK を送信し、CLOSE_WAIT 状態に入ります。ただし、サーバーが close() を実行しない場合、CLOSE_WAIT から LAST_ACK に移行できず、システム内に CLOSE_WAIT 状態の接続が多数存在します。現時点では、システムが読み取りおよび書き込み操作の処理でビジー状態で、FIN を受信した接続を閉じていない可能性があります。この時点で、recv/read は FIN 接続ソケットを受信して​​いるため、0 を返します。

なぜ TIME_WAIT 状態が必要なのでしょうか?

最後の ACK が失われた場合、サーバーは FIN を再送信します。クライアントは、最後の ACK を再送信できるように TCP ステータス情報を維持する必要があります。そうでない場合、サーバーは RST を送信し、エラーが発生したと判断します。発生した。 TCP 実装では、両方向の接続 (全二重がクローズ) を確実に終了する必要があり、クライアントは最終 ACK の再送信に直面する可能性があるため、TIME_WAIT 状態に入らなければなりません。

なぜ TIME_WAIT 状態をこれほど長い間 2MSL に保つ必要があるのでしょうか?

TIME_WAIT 状態が十分な時間維持されない場合 (たとえば、2MSL 未満)、最初の接続は正常に終了します。 2 番目の接続が同じ関連付けられた 5 つ組で表示され、最初の接続からの重複したパケットが到着し、2 番目の接続を妨害します。 TCP 実装では、特定の接続からの重複メッセージが接続終了後に表示されるのを防ぐ必要があるため、TIME_WAIT 状態を十分な長さ (2MSL) 維持します。そうすれば、接続の対応する方向の TCP メッセージは完全に応答されるか、破棄されます。 2 番目の接続を確立するときに混乱することはありません。

TIME_WAIT および CLOSE_WAIT ステータスのソケットが多すぎます

サーバーに例外がある場合、80 ～ 90% の確率で次の 2 つの状況が発生します:

1. サーバーは大量の TIME_WAIT ステータスを維持します

2サーバーは大量の CLOSE_WAIT ステータスを維持します。簡単に言えば、過剰な数の CLOSE_WAIT は、受動的に閉じられた接続の不適切な処理が原因です。

Linuxによってユーザーに割り当てられるファイルハンドルは有限であり、TIME_WAITとCLOSE_WAITの2つの状態が常に維持されるということは、常に対応する数のチャネルが占有されることを意味し、「力を出さずにピットを占有する」ことになるハンドル数の上限に達すると、新しいリクエストを処理できなくなり、Too Many Open Files 例外が大量に発生し、Tomcat がクラッシュします。

以上がLinux チュートリアル: Nginx の同時接続数と接続ステータスのクエリの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。