LinuxでNginxの同時接続数や接続状況を確認する方法を詳しく紹介

Linux 同時接続数やNginxなどの接続ステータスを確認します。

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

netstat -n | awk '/^tcp/ {++state[$NF] } END { for(

key

in state) print key,"t",state[key]}'戻り結果は通常次のとおりです:

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

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

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

LIST

JP: サーバーは着信を待っています 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

File

例外が多数発生し、Tomcat がクラッシュします。

以上がLinuxでNginxの同時接続数や接続状況を確認する方法を詳しく紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。