У меня есть сервер с двухъядерным процессором, 4 ГБ оперативной памяти и ОС Windows Server 2008, который я использую в качестве основного файлового сервера.
Доступ к нему внезапно стал очень медленным. Независимо от того, подключаюсь ли я по RDP или получаю доступ к файлам удаленно через отображенные диски, он просто медленный!
Я могу подключаться по RDP к другим машинам, расположенным в другом штате, через VPN, и они работают гораздо быстрее.
Если я работаю непосредственно на самом сервере, то все быстро. Кажется, это что-то между моим клиентским компьютером(ами) и сервером.
Как мне проверить скорость сетевого соединения между двумя машинами? Или что-то еще, что мне следует проверить?
решение1
За последний год или около того я видел много маленьких дешевых сетевых коммутаторов, которые «сходили с ума». Режим отказа — сверхмедленная передача данных и потеря пакетов. (В прошлом году я видел это в основном с коммутаторами LinkSys). Я подозреваю это, хотя и не обязательно как самое первое. К счастью, простой тест скорости довольно прост с «Общим доступом к файлам и принтерам».
Вы можете провести «быстрый и грубый» тест пропускной способности файлового сервера, создав большой временный файл на клиентском компьютере с помощью команды fsutil, а затем замерив время передачи на серверный компьютер:
fsutil file createnew temp-file-name 209715200
Это создаст временный файл размером 200 МБ. Вы можете сделать быструю копию с синхронизацией, используя следующий скрипт (из каталога, где вы создали временный файл, и предполагая, что у вас есть права на копирование в какой-либо общий ресурс на компьютере-сервере):
@echo off
echo.|time
copy temp-file-name \\server-computer-name\share-name
echo.|time
Вычтите конечное время из начального времени, преобразуйте в секунды и разделите 209715200 на количество прошедших секунд, чтобы получить количество байтов в секунду.
Вы должны увидеть более 7 000 000 байт в секунду (примерно 56 Мбит/с) в локальной сети 100Base-TX. Если значение ниже, я начинаю подозревать, что что-то не так. Если серверный компьютер достаточно современный, он должен без проблем заполнять канал 100 Мбит/с. Если вы видите скорость передачи ниже этой, я бы начал смотреть на счетчики ошибок в интерфейсе администрирования коммутатора, к которому подключены сервер и клиент. У вас могут быть неисправные кабели, несоответствие дуплекса или проблемы с драйвером сетевой карты. Все дело в методичном отслеживании проблемы.
Редактировать: Тест копирования файлов — это хороший тест, потому что вы можете провести его без какого-либо стороннего программного обеспечения. Поскольку вы обнаружили, что узкое место действительно существует, следующим шагом будет определение причины узкого места.
Утилита WSTTCP (доступна по адресуhttp://www.pcausa.com/Utilities/pcattcp.htm) — это быстрый и грязный тест вашего драйвера сетевой карты и оборудования сетевой инфраструктуры. Он отправляет данные, которые не сходят с диска и не записываются на диск, поэтому дисковые подсистемы на клиенте и сервере в конечном итоге выносятся за скобки уравнения.
На одной машине выполните следующее (после распаковки WSTTCP!), чтобы «прослушать» соединение:
wsttcp -r
На другой машине выполните следующее, чтобы передать тест на удаленную машину:
wsttcp -t <hostname>
В Ethernet на 100 Мбит/с вам, возможно, придется изменить команду передачи (повторно выполнив команду приема на приемнике перед повторным запуском передатчика), чтобы отправить больше буферов, поскольку при более длительном тесте вы получите немного более точные цифры:
wsttcp -t -n8192 <hostname>
Это переместит 64 МБ трафика. Увеличьте номер "8192", чтобы отправить больше трафика.
Вам необходимо либо разрешить прослушивателю доступ через брандмауэр на прослушивающем компьютере (TCP-порт 5001 по умолчанию), либо временно отключить брандмауэр.
Если вы видите хорошую скорость передачи с WSTTCP, но медленную передачу с копированием файлов, начните проверять свою дисковую подсистему (и рассмотрите возможность запуска теста жесткого диска). Если сетевые передачи по-прежнему плохие с WSTTCP, продолжайте исследовать сетевую инфраструктуру, кабели, драйверы NIC или оборудование NIC.
Удачной охоты.
решение2
Я бы порекомендовал проверить на вирусы и т. д. Запустите netstat, чтобы увидеть открытые соединения и посмотрите, нет ли чего подозрительного/неожиданного. Вероятно, есть инструменты для проверки пропускной способности между двумя машинами Windows, но я не знаю ни одного. iperf, возможно, мог бы работать в cygwin.
решение3
Выполните команду tracert на ПК назначения, чтобы увидеть, где задержка. Это даст вам подробную статистику о каждом прыжке.
синтаксис, например: tracert 196.12.2.13
решение4
Может быть, это тоже часть проблемы?