Überprüfen Sie die Anzahl gleichzeitiger Verbindungen und den Verbindungsstatus von Nginx usw. unter Linux.
1. Überprüfen Sie die Anzahl gleichzeitiger Anfragen des Webservers (Nginx Apache) und seinen TCP-Verbindungsstatus:
netstat -n | NF]} END {for(a in S) print a, S[a]}'
oder:
netstat -n | NF]} END {for(key in state) print key,"t",state[key]}'Das Rückgabeergebnis ist im Allgemeinen wie folgt:
LAST_ACK 5 (Anzahl der Anfragen, die auf Verarbeitung warten)
SYN_RECV 30
ESTABLISHED 1597 (normaler Datenübertragungsstatus)
FIN_WAIT1 51
FIN_WAIT2 504
TIME_WAIT 1057 (Anzahl der abgeschlossenen Anfragen , wartet auf das Ende der Zeitüberschreitung)
Andere Parameterbeschreibungen:
GESCHLOSSEN: Keine Verbindung ist aktiv oder in Bearbeitung
LISTEN: Der Server wartet auf eingehende Anrufe
SYN_RECV: Eine Verbindungsanfrage wurde gestellt. Eingegangen, wartet auf Bestätigung
SYN_SENT: Die Anwendung wurde gestartet und öffnet eine Verbindung
HERGESTELLT: Normaler Datenübertragungsstatus
FIN_WAIT1: Die Anwendung sagt, dass sie abgeschlossen ist
FIN_WAIT2: Die andere Seite hat der Freigabe zugestimmt
ITMED_WAIT: Warten auf den Tod aller Pakete
CLOSING: Beide Seiten versuchen zu schließen gleichzeitig
TIME_WAIT: Die andere Seite hat eine Freigabe initialisiert
LAST_ACK: Warten auf den Tod aller Pakete
Die drei häufig verwendeten 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 Seiten des Netzwerks 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 unterbrochenen Animationszustand 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 am bemerkenswertesten: 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äße Handhabung passiv geschlossener Verbindungen 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 Anforderungen nicht mehr verarbeitet werden, es kommt zu einer großen Anzahl von Too Many Open Files-Ausnahmen und Tomcat stürzt ab.
Das obige ist der detaillierte Inhalt vonLinux-Tutorial: Abfrage der Anzahl gleichzeitiger Verbindungen und des Verbindungsstatus von Nginx. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
