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