Отладка медленных SMB-пакетов от определенного настольного клиента

У меня возникли серьезные проблемы с поиском замедления, и я надеюсь, что вы могли бы помочь мне с этим.

У нас есть офисная сеть с ~50 клиентами и основным файловым сервером под управлением Windows Server 2008 R2 Standard (SP1). Для одного конкретного клиента (Windows 7, SP1) доступ к общим сетевым ресурсам может иногда быть болезненно медленным, и это можно исправить только после перезагрузки компьютера. Теперь проблема в том, что мы выключили реальный компьютер, и проблема все еще сохраняется. Новый компьютер того же производителя и модели, но у нас есть несколько таких в офисе, и они не сталкивались с этой проблемой.

Также пытались изменить все связанные сетевые кабели, а также использовать разные порты на коммутаторе. Я также попытался войти в систему как другой пользователь AD безрезультатно.

Я запустил WireShark на клиентском компьютере, а также на своем собственном для сравнения, а пакеты SMB на зараженном компьютере в 10-1000 раз медленнее, но только при отправке на файловый сервер. Все SMB-пакеты, отправленные на сервер (как с моего тестового компьютера, так и с зараженного), имеют неверную контрольную сумму заголовка, если это имеет значение.

Это не моя основная область знаний, поэтому мне сложно разобрать журнал WireShark, за исключением того, что я сравниваю его с другим и вижу разницу в затраченном времени между пакетами. По сути, я не уверен, где искать причину проблемы, только последствия.

Ниже приведена статистика количества байтов на такт для двух компьютеров, для некоторых основных навигации и копирования небольшого (~100 КБ) файла на рабочий стол с сетевого диска. Выполнение одного и того же через FTP дает нормальные результаты для обоих компьютеров.

http://www.kommunicera.se/public/bytes-per-tick.png

Файлы PCAP здесь (маленькие) и здесь (большие).

Обратите внимание, что два дампа в pcap-2.zip находятся на одном и том же компьютере, но один - когда он работает нормально, а другой - при замедлении (дампы записываются за минуты).

1 ответ

Решение

Рисунок, я бы обновил это с решением, с которым мы в конечном итоге.

По какой-то причине конкретный драйвер Broadcom NIC, который у нас был, вызывал эту проблему - все затронутые компьютеры имели одинаковый NIC и одну и ту же версию драйвера. Обновление до последнего драйвера решило всю проблему.

Другие вопросы по тегам