Die Ausgabe der
'netstat -anT -p tcp'
Befehl von einem Node zeigt die Anzahl der TCP-Nullfensterpakete an (Spalte 0-win). Die Werte in der Spalte 0-win geben an, wie oft der Node der TCP-Verbindung (lokale Adresse) an das Remotegerät (fremde Adresse) ein TCP-Zero-Window-Updatepaket gesendet hat. Dies tritt auf, wenn das TCP-Empfangsfenster des Node auf Null oder auf eine Größe reduziert wurde, die zu niedrig ist, um in ein Datensegment voller Größe zu passen.
Beispiel:
Cluster-1# netstat -anT -p tcp
Active Internet connections (including servers)
Proto Rexmit OOORcv 0-win maxswnd maxseg srtt srtvar rexmt sndwnd sncwnd rcvwnd delack SR SS ND AS Local Address Foreign Address
tcp4 0 0 1001 2097920 1460 47ms 23ms 342ms 2097664 190488 131400 99ms X X X X 100.89.53.100.445 100.90.164.11.52765
...
Das Nettoergebnis ist, dass das Remotegerät keine Daten übertragen kann, was zu Verzögerungen führt, die zu einer erhöhten Latenz (Schreibvorgängen) führen, bis der Node eine Aktualisierung des TCP-Fensters sendet, die angibt, wie viele Daten er jetzt empfangen kann.
In den meisten Fällen weisen vom Node gesendete TCP-Zero-Window-Aktualisierungspakete darauf hin, dass die empfangende Anwendung (der Prozess) auf dem Node (NFS, SMB usw.) Daten nur langsam aus dem Empfangspuffer abruft. Dies kann durch einen konsistenten Wert ungleich Null angezeigt werden, der in der Spalte Recv-Q für die Verbindung in der Ausgabe der
'netstat -an tcp'
verwenden. Führen Sie beispielsweise den folgenden Befehl mehrmals aus, um zu überprüfen, ob Recv-Q konsistent voll ist.
Beispiel:
Cluster-1# netstat -an tcp
Active Internet connections (including servers)
Proto Recv-Q Send-Q Local Address Foreign Address (state)
tcp4 131400 0 100.89.53.100.445 100.90.164.11.52765 ESTABLISHED
...
Da es sich um einen Echtzeitzähler handelt, muss dieser Befehl ausgeführt werden, während der Knoten Aktualisierungspakete mit dem TCP-Nullfenster für die Verbindung sendet. Im Folgenden finden Sie ein Beispielskript zum Abrufen von Live-Statistiken:
- Recv
- Send-Q's
- Bestellungen abgelaufen (OOO)
- Kein Windows (0-win)
- Überträgt
# mkdir /ifs/data/Isilon_Support/$(date +%d-%m-%Y)/
echo; while sleep 10 ; do echo "######### Live Send Rec Queue Q: #########"; date ; netstat -an4x -p tcp | awk '{ if (( $2 != 0 ) || ($3 != 0)) print $0 }'; echo; sleep 1; echo "######### Live OoO / 0-win / Retrans: #########" ; date; netstat -an4T -p tcp | awk '{ if (( $2 != 0 ) || ($3 != 0) || ($4 != 0)) print $0 }'; done >> `hostname`.TCP_specs.out Ein konstant erhöhter Recv-Q-Wert bedeutet, dass die Daten auf dem Empfangspuffer abgelegt wurden, die Anwendung jedoch recv() nicht aufgerufen hat, um sie vom Empfangspuffer in den Anwendungspuffer zu kopieren. Dies ist ein Hinweis darauf, dass die Anwendung überlastet oder anderweitig nicht in der Lage ist, eingehende Daten rechtzeitig zu verarbeiten. Sobald Daten in der Empfangswarteschlange eintreffen, sollten sie sofort verarbeitet werden. Wenn die Anwendung das nicht tut, wird ihr mehr Arbeit abverlangt, als sie bewältigen kann.
Zusammenfassend lässt sich sagen, dass, wenn der Recv-Q-Wert für die Verbindung erhöht bleibt, während TCP-Zero-Window-Updatepakete für die Verbindung gesendet werden, eine Untersuchung auf Engpässe bei der empfangenden Anwendung, CPU, Festplatten usw. durchgeführt werden sollte.
Wenn der Recv-Q-Wert für die Verbindung bei Null bleibt, dann können die vom Node gesendeten TCP-Zero-Window-Updatepakete auch darauf hinweisen, dass das TCP-Empfangsfenster auf der Node-Seite der Verbindung für das Bandbreitenverzögerungsprodukt (BDP) der Verbindung zwischen dem Node und dem Remoteziel zu niedrig ist, und einige Node-TCP-Tunings müssen möglicherweise berücksichtigt werden.