Windows 2008 Server на смешанных скоростях Ethernet — загружает с доли медленную, но быструю плоскость TCP
Проблема была вызвана:
- слишком маленькими буферами пакетов в недорогом гигабитном коммутаторе;
- неадекватным алгоритмом предотвращения перегрузки, используемым в файловых службах Windows Server 2008;
- отключено управление потоком в сетевой адаптер (по умолчанию он был отключен).
Поскольку управление потоком было отключено, Windows отправляла пакеты размером до размера окна одним пакетом, используя соединение 1 Гбит / с. Поскольку клиент со скоростью 100 Мбит / с получает пакеты намного медленнее, почти все данные вплоть до размера окна необходимо буферизовать с помощью коммутатора. Поскольку этот дешевый коммутатор имеет очень маленькие буферы (размеры буфера даже не указаны в спецификациях, но он должен быть меньше 64 КБ на порт, так как даже отключение масштабирования окна не помогло), ему пришлось отбрасывать лишние пакеты. Потеря пакетов вызвала задержку около 0,25 с, видимую на графике. Но алгоритм предотвращения перегрузки, использование в файловых службах или их отсутствие не уменьшало размер окна TCP, поэтому следующий пакет пакетов не был меньше - он снова и снова перегружал соединение, вызывая коллапс перегрузки .
Стандартные соединения TCP ( не файловые службы) должны использовать другой алгоритм управления перегрузкой и не перегружаться повторно. Я полагаю, что обработка файловых служб с помощью стека TCP Windows помогает в тестах, например, против Samba.
Итак, решения следующие:
Включить управление потоком в свойствах сетевого адаптера. Это не идеальное решение, поскольку любая передача файловых служб клиенту со скоростью 100 Мбит / с также замедлит одновременные передачи клиентов с 1 Гбит / с до скорости менее 100 Мбит / с.
Или подключите клиентов со 100 Мбит / с к коммутатору корпоративного класса с гораздо большими буферами . Это решение, которое я использовал. У меня есть коммутатор "3Com SuperStack 3 3300 SM" 10-летней давности с одним оптоволоконным гигабитным Ethernet-портом MT-RJ 1000Base-SX. Я купил модуль Cisco 1000BASE-SX mini-Gbic (MGBSX1) с портом LC для своего гигабитного коммутатора Linksys и многомодового оптоволоконного патч-корда LC / MT-RJ (около 150 долларов за оба) и подключил всех клиентов со скоростью 100 Мбит / с. к этому коммутатору 3com. Я также включил управление потоком, но оно не должно вызывать замедления при отсутствии подключенного клиента со скоростью 100 Мбит / с.
Спасибо SpacemanSpiff , чьи комментарии помогли решить эту проблему.
Я купил модуль Cisco 1000BASE-SX mini-Gbic (MGBSX1) с портом LC для своего гигабитного коммутатора Linksys и многомодового оптоволоконного патч-корда LC / MT-RJ (около 150 долларов за оба) и подключил всех клиентов со скоростью 100 Мбит / с. к этому коммутатору 3com. Я также включил управление потоком, но оно не должно вызывать замедления при отсутствии подключенного клиента со скоростью 100 Мбит / с.Спасибо SpacemanSpiff , чьи комментарии помогли решить эту проблему.
Я купил модуль Cisco 1000BASE-SX mini-Gbic (MGBSX1) с портом LC для своего гигабитного коммутатора Linksys и многомодового оптоволоконного патч-корда LC / MT-RJ (около 150 долларов за оба) и подключил всех клиентов со скоростью 100 Мбит / с. к этому коммутатору 3com. Я также включил управление потоком, но оно не должно вызывать замедления при отсутствии подключенного клиента со скоростью 100 Мбит / с.Спасибо SpacemanSpiff , чьи комментарии помогли решить эту проблему.
Windows Server включали SMB, Подписывающийся? Подписание SMB добавляет замедление и включено по умолчанию на Контроллерах домена.
-
1
-
2я думаю, что он включен, поскольку он идет по умолчанию. Но я не думаю, что это - причина, поскольку клиенты, соединенные со ссылкой на 1 Гбит/с, не испытывают медленные загрузки с доли. Это не замедлило бы 10-кратный сервер. Я протестирую его, когда возможный, но я думаю, что это очень маловероятно причина. – Tometzky 6 December 2010 в 22:16
-
3Никакой AV на сервере. Отключенный на клиенте Windows XP, никаком AV на клиенте Linux. Никакая высокая загрузка ЦП во время передачи. Тот же клиентский компьютер, подключенный с 1 Гбит/с, быстр, таким образом, это не AV. – Tometzky 6 December 2010 в 22:19
-
4Это, конечно, походит на высокоуровневую проблему. Что относительно того, чтобы делать попытку других протоколов не-CIFS - ftp, scp, tftp и т.д. от медленного клиента? Также не обесценивайте несколько наложенных проблем - Концерт к 100full + SMB передачи Signing/syncronous + 8,3 имен файла + много маленьких файлов с большим количеством метаданных = смерть из-за тысячи сокращений. Наконец, возможно, посмотрите на руководство Мелодии Перфекта R2 2008 года, pp56 вперед? microsoft.com/whdc/system/sysperf/Perf_tun_srv-R2.mspx – AndyN 7 December 2010 в 01:04
-
5я добавил графики передач, хороших и плохих, для сравнения. Возможно, что-то могло быть выведено от них. – Tometzky 7 December 2010 в 17:44
Это могла бы быть карта/переключатель на 100 Мбит/с? Вы упоминаете, что тот же клиент работает правильно, когда это находится на 1 Гбит/с.
-
1Существует несколько клиентов. Некоторые с картами на 100 Мбит/с, некоторые с 1 Гбит/с, некоторые включенные к переключателю на 1 ГБ, некоторым к 100 МБ, который включается к этому 1 ГБ. Все возможные комбинации. Если существует какая-либо ссылка 100 МБ между клиентом и сервером затем, производительность CIFS медленнее, чем 10 МБ, как он 1995 снова. – Tometzky 7 December 2010 в 10:20
Чувствует себя подобно сетевой проблеме низшего уровня. Мои предположения:
- Дуплексные проблемы несоответствия. Это, конечно, снизило бы производительность вполне немного. На стороне Linux используйте команду ethtool, чтобы проверить что Ваше согласование на уровне 100 Мбит/с/полных дуплексов. Если Ваша карта согласовывает в 100/половина, и переключатель думает это, соединение 100/полный, то будут все типы проблем. Вы могли бы хотеть экспериментировать с принуждением 100/полный вместо того, чтобы автосогласовать скорость (помните, что необходимо вызвать 100/полный в переключателе и системе),
- Это могла также быть буферная проблема или на сетевой плате клиента или на переключателе. Я видел, что Драйверы сетевой платы не выделяют достаточно места буфера и вызываю проблемы со скоростью. Я предполагаю, что тот же тип проблемы мог произойти на переключателе. Намного тяжелее диагностировать, другое затем подкачивающее оборудование.
Вы могли попытаться скопировать через esetutil (если у Вас есть Exchange Server там),
Проверьте это: http://blogs.technet.com/b/askperf/archive/2007/05/08/slow-large-file-copy-issues.aspx
Это могло быть тестом при копировании больших файлов от клиента к серверу или наоборот протестировать, если esetutil получают лучшую производительность.
также у меня были подобные проблемы с Сервером Windows 2008 и Linux с опцией под названием NetDMA (последний раздел). Это решило мои проблемы (был Сетевой адаптер Broadcom с объединением в команду),
Как включить и отключить NetDMA в Windows Server 2008, Чтобы включить или отключить NetDMA, выполните эти шаги: Нажмите Start, нажмите Run, введите regedit и затем нажмите "OK". Найдите следующий подраздел реестра и затем нажмите его: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters Дважды щелкают по ключу реестра EnableTCPA. Отметьте, не Существует ли этот ключ реестра, щелкните правой кнопкой по Parameters, укажите на Новый, нажмите DWORD Value, введите EnableTCPA и затем нажмите ENTER. Включить NetDMA, тип 1 в поле данных Значения, и затем нажать "OK". Отключить NetDMA, тип 0 в поле данных Значения, и затем нажать "OK". Если ключ реестра EnableTCPA не существует, добавьте функциональность NetDMA. Сторонние продукты, которые обсуждает эта статья, произведены компаниями, которые независимы от Microsoft. Microsoft не дает гарантии, подразумеваемой или иначе, о производительности или надежности их продукт
от базы знаний Microsoft 951037 поддержки
Check if the BIOS of your servers/clients has a "CPU C State" parameter (probably inside the Power Saving category). If present, try setting that parameter to DISABLE.