web-dev-qa-db-ja.com

Windows共有に大きなファイルを書き込むときにTCP ZeroWindowを防ぐ方法は？

ファイルサーバーとプリンターサーバーであるWindows Server 2003 SP1システム（10.a.bbb.ccc）上の共有へのアクセス権が与えられ、定期的に大きなファイルがその共有にコピーされます。ただし、このようなコピーが失敗することがあります。 Robocopy（10.xxx.yy.zzz）を使用してこの問題を再現すると、次のような結果になります

 70.4%
2013/07/31 11:20:21 ERROR 64 (0x00000040) Copying File <<file name removed>>
The specified network name is no longer available.

Waiting 30 seconds... Retrying...
         New File          105.2 m   <<file name removed>>
  0.0%

dumpcap + Wiresharkは、これが発生すると、ウィンドウサイズをゼロに設定することにより、コピーの最中にサーバーが突然TCPポート445でデータを一切受け入れないことを示しています。

No.     Time           Source                Destination           Protocol Length Info
   7303 5.841186000    10.a.bbb.ccc          10.xxx.yy.zzz         TCP      60     [TCP ZeroWindow] Microsoft-ds > 57918 [ACK] Seq=10864 Ack=6973070 Win=0 Len=0
   7304 6.149715000    10.xxx.yy.zzz         10.a.bbb.ccc          TCP      55     [TCP ZeroWindowProbe] [TCP segment of a reassembled PDU]
   7305 6.150137000    10.a.bbb.ccc          10.xxx.yy.zzz         TCP      60     [TCP ZeroWindowProbeAck] [TCP ZeroWindow] Microsoft-ds > 57918 [ACK] Seq=10864 Ack=6973070 Win=0 Len=0
   7306 6.749711000    10.xxx.yy.zzz         10.a.bbb.ccc          TCP      55     [TCP ZeroWindowProbe] [TCP segment of a reassembled PDU]
   7307 6.750087000    10.a.bbb.ccc          10.xxx.yy.zzz         TCP      60     [TCP ZeroWindowProbeAck] [TCP ZeroWindow] Microsoft-ds > 57918 [ACK] Seq=10864 Ack=6973070 Win=0 Len=0
   7308 7.946779000    10.xxx.yy.zzz         10.a.bbb.ccc          TCP      55     [TCP ZeroWindowProbe] [TCP segment of a reassembled PDU]
   7309 7.947130000    10.a.bbb.ccc          10.xxx.yy.zzz         TCP      60     [TCP ZeroWindowProbeAck] [TCP ZeroWindow] Microsoft-ds > 57918 [ACK] Seq=10864 Ack=6973070 Win=0 Len=0
   7310 10.349783000   10.xxx.yy.zzz         10.a.bbb.ccc          TCP      55     [TCP ZeroWindowProbe] [TCP segment of a reassembled PDU]
   7311 10.350201000   10.a.bbb.ccc          10.xxx.yy.zzz         TCP      60     [TCP ZeroWindowProbeAck] [TCP ZeroWindow] Microsoft-ds > 57918 [ACK] Seq=10864 Ack=6973070 Win=0 Len=0
   7312 15.149910000   10.xxx.yy.zzz         10.a.bbb.ccc          TCP      55     [TCP ZeroWindowProbe] [TCP segment of a reassembled PDU]
   7313 15.150283000   10.a.bbb.ccc          10.xxx.yy.zzz         TCP      60     [TCP ZeroWindowProbeAck] [TCP ZeroWindow] Microsoft-ds > 57918 [ACK] Seq=10864 Ack=6973070 Win=0 Len=0
   7314 24.747096000   10.xxx.yy.zzz         10.a.bbb.ccc          TCP      55     [TCP ZeroWindowProbe] [TCP segment of a reassembled PDU]
   7315 24.756210000   10.a.bbb.ccc          10.xxx.yy.zzz         TCP      60     [TCP ZeroWindowProbeAck] [TCP ZeroWindow] Microsoft-ds > 57918 [ACK] Seq=10864 Ack=6973070 Win=0 Len=0
   7316 43.958531000   10.xxx.yy.zzz         10.a.bbb.ccc          TCP      55     [TCP ZeroWindowProbe] [TCP segment of a reassembled PDU]
   7317 43.958863000   10.a.bbb.ccc          10.xxx.yy.zzz         TCP      60     [TCP ZeroWindowProbeAck] [TCP ZeroWindow] Microsoft-ds > 57918 [ACK] Seq=10864 Ack=6973070 Win=0 Len=0
   7318 75.216401000   10.xxx.yy.zzz         10.a.bbb.ccc          TCP      54     57918 > Microsoft-ds [RST, ACK] Seq=6973070 Ack=10864 Win=0 Len=0
   7319 75.225543000   10.xxx.yy.zzz         10.a.bbb.ccc          TCP      66     55972 > Microsoft-ds [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
   7320 75.225933000   10.a.bbb.ccc          10.xxx.yy.zzz         TCP      66     Microsoft-ds > 55972 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=1 SACK_PERM=1

したがって、70秒後、クライアント（ここではRobocopy）はそれを終了すると呼びます。

私の質問：これはWindows共有の既知の問題ですか？ファイルサーバーで何を調査/デバッグ/追跡できますか？確認または実験する必要がある特定の設定はありますか？

前もって感謝します！

windowsnetworkingtcpserver-message-blocktcp-window
4
MarnixKlooster ReinstateMonica

私は@suprjamiに同意し、この探索可能な道を提供したいと思います。サーバーのディスクが遅すぎるではなく、障害が発生している可能性があることを考慮してください（通常、ハードドライブが不良あたり約8秒間フリーズします）クラスターの読み取り）、非常に断片化、スペース不足（深刻な断片化と重いディスクスラッシングの原因）、またはネットワークとディスクサブシステムを含む他のすべてのリソースが不足しているマシンで、CPUに大きく依存するタスクまたはディスクに依存するタスクがある可能性があります。サーバーのイベントビューアーでディスクエラーを確認し、タスクマネージャーまたはプロセスエクスプローラーをいくつかの列でプルアップして、ページフォールト、CPU使用率、I/O読み取りバイト数と書き込みバイト数を表示し、数値が何をしているかを確認することをお勧めします。

ZeroWindowがTCP受信バッファーがいっぱいになっていることの症状であることを考えると、問題はサーバーで100％のCPUを消費している、または非常に過剰なネットワークトラフィックがサーバーとすべてをロックします。

もう1つの可能性は、中間デバイスのTCP実装、そのデバイスが何らかの方法でリレーするパケットを変更している場合（つまり、NAT）のバッファブロートです。転送が急上昇し、転送レートが偶然に低下します？

3
Jody Lee Bruchon

TCPチューニングパラメータを確認する前に（TCPスタックを調整できますが、99.9％の時間、自動スケーリングは正常に機能します）、もう少し背景を説明しますか？例：受信サーバーの仕様は何ですか、クライアントとサーバーの両方が同じレイヤー2ネットワーク上にあり、NICはどのくらいの速度で実行されているかなど.

また、ROBOCOPYの/ IPGパラメーター、おそらく/ R：および/ W：（再試行と待機）パラメーターを試してみる価値はありますか？

0
Simon Catlin

TCPゼロウィンドウとは、受信ホストが圧倒されていることを意味します。すでに取得したものを処理するために時間が必要なため、送信側ホストにデータの送信を停止するように指示しました。

サーバーのディスクが遅すぎるようで、クライアントはやがて接続を断念してタイムアウトします。

クライアントを離れるときに転送速度を遅くするか、サーバーに高速のディスクを入れます。

0
suprjami