Solucionar problemas de pacotes de atualização da janela zero do TCP enviados por um nó do PowerScale

O resultado do

 'netstat -anT -p tcp'

de um nó mostra uma contagem de pacotes de janela zero TCP (coluna 0-win). Os valores na coluna 0-win indicam a quantidade de vezes que o nó da conexão TCP (endereço local) com o dispositivo remoto (endereço externo) enviou um pacote de atualização da janela zero TCP. Isso ocorre quando a janela de recebimento de TCP do nó é reduzida a zero ou a um tamanho muito baixo para caber em um segmento de dados de tamanho normal.
Exemplo:

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

O resultado disso é que o dispositivo remoto não poderá transmitir dados, introduzindo atrasos que resultarão em latência (gravação) elevada, até que o nó envie uma atualização da janela TCP indicando a quantidade de dados que pode receber agora. 
Na maioria dos casos, os pacotes de atualização da janela zero do TCP enviados pelo nó indicam que o aplicativo (processo) de recebimento no nó (NFS, SMB etc.) está lento para extrair dados do buffer de recebimento. Isso pode ser indicado por um valor diferente de zero consistente visto na coluna Recv-Q para a conexão na saída do

 'netstat -an tcp'

hostname. Por exemplo, execute o seguinte comando várias vezes para ver se o Recv-Q está consistentemente cheio.
Exemplo:

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

Esse é um contador em tempo real, portanto, esse comando precisará ser executado enquanto os pacotes de atualização da janela zero do TCP estiverem sendo enviados pelo nó para a conexão. A seguir, apresentamos um exemplo de script para recuperar estatísticas dinâmicas:

• Recv
• Enviar Q s
• Fora de pedidos (OOO)
• Zero Windows (0-win)
• Retransmite

# 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

Um Recv-Q constantemente elevado significa que os dados foram colocados no buffer de recebimento, mas o aplicativo não chamou recv() para copiá-los do buffer de recebimento para o buffer do aplicativo. Essa é uma indicação de que o aplicativo está sobrecarregado ou não consegue processar os dados recebidos em tempo hábil. Assim que os dados chegam à fila de recebimento, eles devem ser processados imediatamente, se o aplicativo não estiver fazendo isso, então ele está sendo solicitado a fazer mais trabalho do que ele pode lidar. 
Em resumo, se o valor de Recv-Q permanecer elevado para a conexão enquanto os pacotes de atualização da janela zero do TCP estiverem sendo enviados para a conexão, uma investigação sobre gargalos deverá ser realizada no aplicativo receptor, CPU, discos etc.
Se o valor de Recv-Q permanecer em zero para a conexão, os pacotes de atualização da janela TCP zero enviados pelo nó também podem indicar que a janela de recebimento de TCP no lado do nó da conexão é muito baixa para começar com o produto de atraso de largura de banda (BDP) da conexão entre o nó e o destino remoto, e alguns ajustes de TCP do nó podem precisar de consideração.

Consulte a seção "Latência, largura de banda e throughput" do seguinte guia para obter mais informações:

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