Detaillierte Einführung zum Überprüfen der Anzahl gleichzeitiger Verbindungen und des Verbindungsstatus von Nginx unter Linux

Linux Überprüfen Sie die Anzahl gleichzeitiger Verbindungen und den Verbindungsstatus von Nginx usw.

1. Überprüfen Sie die Anzahl gleichzeitiger Anfragen des Webservers (Nginx Apache) und seinen TCP-Verbindungsstatus:

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

oder:

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

key in state) print key,"t",state[key]}'Das Rückgabeergebnis ist im Allgemeinen wie folgt folgt:

LAST_ACK 5 （正在等待处理的请求数）
SYN_RECV 30 
ESTABLISHED 1597 （正常数据传输状态） 
FIN_WAIT1 51 
FIN_WAIT2 504 
TIME_WAIT 1057 （处理完毕，等待超时结束的请求数）

Andere Parameterbeschreibungen:

GESCHLOSSEN: Keine Verbindung ist aktiv oder in Bearbeitung

LISTEEN: Der Server wartet auf Eingehende Anrufe

SYN_RECV: Eine Verbindungsanfrage ist eingetroffen und wartet auf Bestätigung

SYN_SENT: Die Anwendung wurde gestartet und öffnet eine Verbindung

ESTABLISHED: Normaler Datenübertragungsstatus

FIN_WAIT1: Die Anwendung meldet, dass sie abgeschlossen ist

FIN_WAIT2: Die andere Seite hat der Freigabe zugestimmt

ITMED_WAIT: Warten, bis alle

Gruppen sterben

CLOSING: Beide Seiten versuchen gleichzeitig zu schließen

TIME_WAIT: Die andere Seite hat eine Freigabe initialisiert

LAST_ACK: Warten auf den Tod aller Pakete

Die drei Häufig verwendete Zustände sind: ESTABLISHED bedeutet Kommunikation, TIME_WAIT bedeutet aktives Schließen und CLOSE_WAIT bedeutet passives Schließen.

Das TCP-Protokoll schreibt vor, dass für eine hergestellte Verbindung beide Parteien im Netzwerk einen Vier-Wege-Handshake durchführen müssen, um die Verbindung erfolgreich zu trennen. Wenn einer dieser Schritte fehlt, befindet sich die Verbindung in einem angehaltenen Zustand. und die von der Verbindung selbst belegten Ressourcen werden nicht freigegeben. Das Netzwerkserverprogramm muss eine große Anzahl von Verbindungen gleichzeitig verwalten. Daher muss sichergestellt werden, dass nutzlose Verbindungen vollständig getrennt werden, da sonst eine große Anzahl toter Verbindungen viele Serverressourcen verschwendet. Unter den vielen TCP-Zuständen gibt es zwei bemerkenswerteste Zustände: CLOSE_WAIT und TIME_WAIT.

TIME_WAIT

TIME_WAIT wird gebildet, wenn der Link aktiv geschlossen wird und 2MSL Zeit, etwa 4 Minuten, gewartet wird. Hauptsächlich, um zu verhindern, dass die letzte ACK verloren geht. Da TIME_WAIT sehr lange dauern wird, sollte der Server versuchen, die Anzahl der aktiven geschlossenen Verbindungen zu reduzieren

CLOSE_WAIT

CLOSE_WAIT wird durch passives Schließen von Verbindungen gebildet. Wenn der Server gemäß der TCP-Statusmaschine die vom Client gesendete FIN empfängt, sendet er gemäß der TCP-Implementierung eine ACK und wechselt daher in den Status CLOSE_WAIT. Wenn der Server jedoch close() nicht ausführt, kann er nicht von CLOSE_WAIT zu LAST_ACK migrieren, und im System befinden sich viele Verbindungen im CLOSE_WAIT-Status. Zu diesem Zeitpunkt ist das System möglicherweise mit der Verarbeitung von Lese- und Schreibvorgängen beschäftigt und hat die Verbindung, die FIN empfangen hat, nicht geschlossen. Zu diesem Zeitpunkt hat recv/read den FIN-Verbindungssocket empfangen und gibt 0 zurück.

Warum brauchen wir den Status TIME_WAIT?

Angenommen, die endgültige Bestätigung geht verloren, sendet der Server die FIN erneut. Der Client muss die TCP-Statusinformationen beibehalten, damit die endgültige Bestätigung erneut gesendet werden kann, was zum Nachdenken des Servers führt dass ein Fehler aufgetreten ist. TCP-Implementierungen müssen beide Richtungen der Verbindung zuverlässig beenden (Vollduplex geschlossen), und der Client muss in den TIME_WAIT-Status wechseln, da der Client möglicherweise mit der erneuten Übertragung des endgültigen ACK konfrontiert wird.

Warum muss der TIME_WAIT-Status so lange auf 2MSL bleiben?

Wenn der TIME_WAIT-Status nicht lange genug beibehalten wird (z. B. weniger als 2 MSL), wird die erste Verbindung normal beendet. Es erscheint eine zweite Verbindung mit demselben zugehörigen Fünffach, und es treffen doppelte Pakete von der ersten Verbindung ein, die die zweite Verbindung stören. Die TCP-Implementierung muss verhindern, dass nach dem Beenden der Verbindung doppelte Nachrichten von einer bestimmten Verbindung angezeigt werden. Behalten Sie daher den TIME_WAIT-Status lange genug (2MSL) bei, damit die TCP-Nachrichten in der entsprechenden Richtung der Verbindung entweder vollständig beantwortet oder verworfen werden. Es gibt keine Verwirrung beim Aufbau einer zweiten Verbindung.

Zu viele Sockets im TIME_WAIT- und CLOSE_WAIT-Status

Wenn es eine Ausnahme auf dem Server gibt, sind das in 89 % der Fälle die folgenden zwei Situationen:

1. Der Server behält eine große Anzahl von TIME_WAIT-Status bei

2. Der Server behält eine große Anzahl von CLOSE_WAIT-Status bei. Einfach ausgedrückt wird die übermäßige Anzahl von CLOSE_WAIT durch unsachgemäßes passives Schließen der

Verbindungsverarbeitung verursacht .

Da das einem Benutzer von Linux zugewiesene Dateihandle begrenzt ist und die beiden Zustände TIME_WAIT und CLOSE_WAIT immer beibehalten werden, bedeutet dies, dass immer die entsprechende Anzahl von Kanälen belegt ist und „ belegt. „Kein Aufwand“, sobald die Obergrenze der Anzahl der Handles erreicht ist, können neue Anfragen nicht mehr verarbeitet werden, gefolgt von einer großen Anzahl von Too Many Open

Files-Ausnahmen und Tomcat stürzt ab.

Das obige ist der detaillierte Inhalt vonDetaillierte Einführung zum Überprüfen der Anzahl gleichzeitiger Verbindungen und des Verbindungsstatus von Nginx unter Linux. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!