L'output di
'netstat -anT -p tcp'
da un nodo mostra il conteggio dei pacchetti della finestra zero TCP (colonna 0-win). I valori nella colonna 0-win indicano il numero di volte in cui il nodo della connessione TCP (indirizzo locale) al dispositivo remoto (indirizzo esterno) ha inviato un pacchetto di aggiornamento della finestra TCP zero. Ciò si verifica quando la finestra di ricezione TCP del nodo è stata ridotta a zero o a una dimensione troppo bassa per adattarsi a un segmento di dati di dimensioni standard.
Esempio:
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
...
Il risultato è che il dispositivo remoto non sarà in grado di trasmettere dati, introducendo ritardi che determinano un'elevata latenza (scrittura), fino a quando il nodo non invierà un aggiornamento della finestra TCP indicando la quantità di dati che ora può ricevere.
Nella maggior parte dei casi, i pacchetti di aggiornamento della finestra zero TCP inviati dal nodo indicano che l'applicazione ricevente (processo) sul nodo (NFS, SMB e così via) è lenta nell'estrarre i dati dal buffer di ricezione. Ciò può essere indicato da un valore costante diverso da zero visualizzato nella colonna Recv-Q per la connessione nell'output del
'netstat -an tcp'
. Ad esempio, eseguendo più volte il seguente comando per verificare se il Recv-Q è costantemente pieno.
Esempio:
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
...
Si tratta di un contatore in tempo reale, pertanto questo comando dovrà essere eseguito mentre i pacchetti di aggiornamento della finestra zero TCP vengono inviati dal nodo per la connessione. Di seguito è riportato uno script di esempio per recuperare le statistiche in tempo reale da:
- Recv
- Invia-Q
- Ordini non evasi (OOO)
- Zero Windows (0-win)
- Ritrasmissioni
# 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 Un Recv-Q costantemente elevato significa che i dati sono stati inseriti nel buffer di ricezione, ma l'applicazione non ha chiamato recv() per copiarli dal buffer di ricezione al buffer dell'applicazione. Ciò indica che l'applicazione è sovraccarica o altrimenti non è in grado di elaborare tempestivamente i dati in ingresso. Non appena i dati arrivano nella coda di ricezione, devono essere elaborati immediatamente. Se l'applicazione non lo fa, le viene chiesto di eseguire più lavoro di quello che è in grado di gestire.
In sintesi, se il valore Recv-Q rimane elevato per la connessione mentre vengono inviati pacchetti di aggiornamento della finestra zero TCP per la connessione, è necessario eseguire un'indagine sui colli di bottiglia nell'applicazione ricevente, nella CPU, nei dischi e così via.
Se il valore Recv-Q rimane a zero per la connessione, i pacchetti di aggiornamento della finestra zero TCP inviati dal nodo possono anche indicare che la finestra di ricezione TCP sul lato nodo della connessione è troppo bassa per iniziare per il prodotto di ritardo della larghezza di banda (BDP) della connessione tra il nodo e la destinazione remota e potrebbe essere necessario prendere in considerazione alcune ottimizzazioni TCP del nodo.