Как предотвратить TCP ZeroWindow при записи большого файла в общий ресурс Windows?
Мне был предоставлен доступ к общему ресурсу в системе 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? Что можно исследовать / отлаживать / отслеживать на файловом сервере? Существуют ли какие-то конкретные настройки, на которые мы должны обратить внимание или поэкспериментировать?
Заранее спасибо!
3 ответа
Я согласен с @suprjami и хотел бы предложить этот возможный путь исследования: вместо того, чтобы диски сервера были слишком медленными, учтите, что они могут либо выходить из строя (обычные жесткие диски зависают примерно на 8 секунд при неудачном чтении кластера), сильно фрагментированные, нехватка места (вызывающая серьезную фрагментацию и сильное перебивание диска), или у вас может быть сильно связанная с процессором или диском задача на машине, которая истощает все остальное, включая сетевую и дисковую подсистемы. Я рекомендую проверить средство просмотра событий сервера на наличие ошибок на диске и вызвать диспетчер задач или обозреватель процессов с несколькими столбцами, чтобы показать ошибки страниц, использование ЦП и байты чтения ввода-вывода и записи байтов, а также посмотреть, что делают числа.
Учитывая, что ZeroWindow является признаком переполнения приемного буфера TCP, я готов поспорить, что проблема заключается в том, что он потребляет 100% ЦП на сервере или что-то вызывает чрезмерно чрезмерный сетевой трафик на сервере и блокировку всего.
Еще одна возможность - буферизация в реализации TCP промежуточного устройства, если это устройство каким-либо образом модифицирует пакеты, которые оно передает (например, NAT). Ваши переводы резко увеличиваются и случайно снижаются?
Нулевое окно TCP означает, что принимающий хост перегружен. Он сказал отправляющему хосту прекратить отправку данных, так как ему нужно некоторое время, чтобы обработать то, что он уже получил.
Похоже, что диски на сервере слишком медленные, и клиент в конечном итоге сдается и раз разрывает соединение.
Замедляйте передачу, когда она покидает клиента, или устанавливайте более быстрые диски на сервере.
Прежде чем посмотреть на параметры настройки TCP (вы можете настроить стек TCP в Windows, но в 99,9% случаев он автоматически масштабируется), не могли бы вы дать немного больше информации? Например: какова спецификация принимающего сервера, являются ли клиент и сервер одной и той же сетью уровня 2, с какой скоростью работают сетевые адаптеры и т. д.
Кроме того, стоило ли экспериментировать с параметром ROBOCOPY /IPG, возможно, с параметрами /R: и /W: (повторить и подождать)?