Недавно мы переместили машину с общим файловым доступом, которая работает на Hyper-v 2008 года, в наш центр обработки данных из нашей локальной сети, и теперь она периодически работает очень медленно.
Сети связаны через широкую сеть Ethernet. Проверка связи с сервером возвращается менее чем через 1 мс, а tracert снова показывает только 1 переход с интервалом менее 1 мс. Другие службы, предоставляемые из этого места, похоже, не пострадали (DC, Active Directory, интрасеть и т. Д.)
1 1 мс <1 мс <1 мс 192.168.XX.XX
Кроме местоположения, в сервере ничего не изменилось, включая IP-адрес.
Загрузка простого листа Excel может занять до 2 минут. Просмотр акций также может быть медленным.
Любые идеи?
Пара вещей, которые нужно проверить:
Определите, меньше ли MTU, чем мы ожидаем для обычного Ethernet. С клиентской рабочей станции:
пинг -f -l 1472
Если он возвращает «Пакет должен быть фрагментирован, но DF установлен» (или «Тайм-аут запроса истек»), продолжайте уменьшать с 1472 до тех пор, пока не определите максимальную полезную нагрузку. MTU - это максимальная полезная нагрузка плюс 28 байтов (8 байтов для заголовка ICMP + 20 байтов для заголовка IP, нормальный MTU Ethernet составляет 1500).
Затем в Wireshark и MS Network Monitor 3.3 вы можете добавить столбец «Длина кадра». Это позволит вам увидеть, отправляет ли сервер фреймы Ethernet слишком большого размера. Создайте фильтр отображения или захвата для пакетов размером> 1514 байт, однако сервер действительно не должен отправлять пакеты, размер которых превышает MTU.
Если есть кадры слишком большого размера, они определяются свойствами сетевого адаптера «Большая отправка, разгрузка» и «Jumbo-пакеты» в гостевой системе.
Снижать производительность сервера Windows может не только простая задержка TCP. Если вы готовы, используйте сниффер, например Wireshark, на клиенте, у которого наблюдается медленная загрузка листов Excel, и посмотрите, как это выглядит в сети. Возможно, вы увидите подозрительные таймауты между пакетами, например странные интервалы в 200 мс между пакетами. Затем сравните аналогичный трафик с незатронутой машиной без виртуальной машины, чтобы увидеть, как он должен выглядеть.
Настройки сетевого драйвера. Когда вы перешли на HyperV, вы неизбежно изменили драйвер сетевой карты. Настройки здесь могут влиять на трафик таким образом, что пинг не может диагностировать или выявить. Подобные вещи лучше всего проявляются в ваших действиях: копировании файлов из системы, создании соединений, просмотре общих ресурсов. Даже если он переместился с одной точки HyperV на другую, версии драйверов могут немного отличаться.
Но потоки пакетов должны пролить больше света на проблемы.
Уже есть хорошие предложения, на которые стоит обратить внимание. Еще одна распространенная проблема, с которой я столкнулся, связана с разгрузкой TCP Chimney, особенно с сетевыми адаптерами Broadcom. Попробуйте отключить его и проверить, вступит ли он в игру. http://support.microsoft.com/kb/951037