Felsöka TCP-nollfönsteruppdateringspaket som skickas av en PowerScale-nod

Utdata från

 'netstat -anT -p tcp'

Kommandot från en nod visar antalet TCP-nollfönsterpaket (0-win-kolumn). Värdena i kolumnen 0-win anger hur många gånger noden för TCP-anslutningen (lokal adress) till fjärrenheten (extern adress) hade skickat ett TCP-nollfönsteruppdateringspaket. Detta inträffar när nodens TCP-mottagningsfönster har minskats till noll eller till en storlek som är för låg för att passa ett fullstort datasegment.
Exempel:

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
...

Nettoresultatet av detta är att fjärrenheten inte kan överföra data, vilket medför fördröjningar som resulterar i förhöjd svarstid (skrivning) tills noden skickar en TCP-fönsteruppdatering som anger hur mycket data den nu kan ta emot. 
I de flesta fall indikerar TCP-nollfönsteruppdateringspaket som skickas av noden att det mottagande programmet (processen) på noden (NFS, SMB osv.) är långsam med att hämta data från mottagningsbufferten. Detta kan indikeras av ett konsekvent värde som inte är noll som visas i kolumnen Recv-Q för anslutningen i utgången av

 'netstat -an tcp'

Kommandot. Du kan till exempel köra följande kommando flera gånger för att se om Recv-Q är konsekvent full.
Exempel:

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
...

Det här är en realtidsräknare, så det här kommandot måste köras medan TCP-nollfönsteruppdateringspaket skickas av noden för anslutningen. Följande är ett exempelskript för att hämta livestatistik från:

• Recv
• Skicka-Q
• Slut på beställningar (OOO)
• Noll Windows (0-win)
• Återutsändningar

# 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

En ständigt förhöjd Recv-Q innebär att data har placerats i mottagningsbufferten, men programmet har inte anropat recv() för att kopiera den från mottagningsbufferten till programbufferten. Detta är en indikation på att programmet är överbelastat eller på annat sätt inte kan bearbeta inkommande data i tid. Så snart data kommer in i mottagningskön bör de bearbetas omedelbart, om programmet inte gör det uppmanas det att göra mer arbete än det kan hantera. 
Sammanfattningsvis, om Recv-Q-värdet förblir förhöjt för anslutningen medan TCP-nollfönsteruppdateringspaket skickas för anslutningen, bör en undersökning av flaskhalsar utföras på det mottagande programmet, CPU, diskar osv.
Om Recv-Q-värdet förblir noll för anslutningen kan TCP-nollfönsteruppdateringspaket som skickas av noden också tyda på att TCP-mottagningsfönstret på nodsidan av anslutningen är för lågt till att börja med för BDP (bandbredd-fördröjning-produkt) för anslutningen mellan noden och fjärrmålet, och vissa TCP-justeringar för noder kan behöva övervägas.

Mer information finns i avsnittet "Latens, bandbredd och genomströmning" i följande guide:

https://www.delltechnologies.com/asset/en-us/products/storage/industry-market/h16463-isilon-advanced-networking-fundamentals.pdf