none
Windows Server 2019. Сетевой трафик TX (10Gbit) имеет прерывистый характер с провалами скорости до нуля. RRS feed

  • Pergunta

  • Добрый день!

    Имею тестовый стенд собранный из двух серверов.
    При копировании файлов большого размера (например 50GB и 150GB) c сервера в сетевое расположение наблюдаю странный эффект, см. ниже. Прошу помочь разобраться в причинах происходящего и найти способ решения.

    При любом варианте сетевого соединения, напрямую или через коммутатор 10G, сетевой трафик, исходящий с локального диска первого сервера через порт сетевого адаптера Intel X520DA2 имеет прерывистый, "импульсный" характер.

    При просмотре в Диспетчере задач сетевого трафика копирования файла видим следующее:
     - первоначально копирование с максимальной скоростью дисковой подсистемы продолжается секунд 8-10
     - далее скорость падает до нуля на 2-3 сек.
     - возобновляется на 4-5сек до максимальной скорости
     - снова падает и восстанавливается, и так до конца процесса копирования.
     - Средняя скорость оказывается примерно на уровне 65% от максимальной, исходя их хронометража времени копирования файла.

    Если поменять направления копирования, и заливать файл из сетевой папки, расположенной на втором сервере, на локальный диск первого - 
    копирование идет на полной скорости, с легкими изменениями скорости от 990 до 1050 mb/c 

    Если фокус действий зеркально перенести на второй сервер и проделать точно такие же тесты с копированием в сетевую папку на первом, то увидим ровно те же "странности"

    Если измерять скорость передачи в обеих направлениях утилитой iperf3 никаких проблем не обнаруживается, а сетевое соединение полностью утилизируется и претензий к нему нет.

    Тестировались две версии Windows Server (2016/2019) - проблема одинаково проявляет себя на обеих версиях.

    Не понимаю, где содержится узкое место, как его найти, и какие меры принять, чтобы решить проблему.

    Дополнительная информация:

    CPU Xeon E5-2640 v4
    m/b Supermicro X10SRL-F или X10SRi-F
    Контроллер LSI SAS HBA 9300-8i (ssd подключены к портам этого контроллера).
    6 х Intel SSD DC4510 480gb
    Сетевой адаптер Intel X520DA2 SFP+ (трансиверы, кабели совместимы и исправны).

    Адаптеры инсталлированы в слоты поддерживающие PCI-E 3.0 x8.  
    На серверах установлен Windows Server 2019 с последними обновлениями.
    Установлены последние драйверы устройств с сайтов их производителей.
    Встроенные на m/b 1G адаптеры отключены.
    На адаптере Intel X520DA2 один порт активен и подключен к сети, второй отключен.
    Для теста, на каждом сервере, из SSD дисков средствами Windows собран pool, эквивалентный Raid10, который при чтении отдает 1.05GB. 

    sábado, 12 de dezembro de 2020 20:15

Todas as Respostas

  • Попробуйте установить данное значение в 1:

    HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\DisableBandwidthThrottling

    Однако не ясно в этом ли дело. Поведение напоминает сливание данных в буфер с остановкой передачи данных до освобождения какой то части буфера. Буфер может быть частью редиректорa (на приеме), использоваться драйвером RAID контроллера или даже быть SLC буфером в SSD.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    sábado, 12 de dezembro de 2020 23:58
    Moderador
  • Благодарю за ответ.... )

    Хм... на данных серверах также находятся RAID-контроллеры LSI SAS 9271-8i (на одном) и LSI SAS 9266-8i (на втором). На них висят старые массивы, которые используются для РК.

    На всех SAS контроллерах (и RAID, и HBA) последние прошивки, что есть у Avago по этому старью и последние драйверы. В HCL матерей данное железо перечислено, если мне память не изменяет.

    Не может ли этот факт влиять на поведение серверов и приводить к проблеме??

    Могут ли какие-то настройки BIOS приводить к такой проблеме?

    domingo, 13 de dezembro de 2020 00:50
  • Такого ключа в реестре нет. Создать? REG_DWORD?
    domingo, 13 de dezembro de 2020 01:01
  • Да, конечно создайте. Обратите внимание что это настройка на клиенте.

    This posting is provided "AS IS" with no warranties, and confers no rights.

    domingo, 13 de dezembro de 2020 17:53
    Moderador
  • Ключ реестра не помог. Он был добавлен на оба сервера. Обе машины перезагружены, после чего тест показал, что никаких изменений не произошло.

    Коллеги! Еще есть идеи?

     


    • Editado rapidon domingo, 13 de dezembro de 2020 22:52
    domingo, 13 de dezembro de 2020 21:19
  • Ключ реестра не помог. Он был добавлен на оба сервера. Обе машины перезагружены, после чего тест показал, что никаких изменений не произошло.

     

    Значит проблема не в тротлинге на клиенте. И надо копать дальше.

    Вопрос лишь в том надо ли копать дальше? Это очевидно очень тестовый сценарий когда на сервер записывают очень большой файл в монопольном режиме. Что то мне подсказывает что в реальной жизни это ни на что влиять не будет. 

    Кстати, я что то не вижу модели DC4510 на 480 GB. Вижу ряд от 1 до 8 ТБ.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    domingo, 13 de dezembro de 2020 22:27
    Moderador
  • Виноват, перепутал модель SSD, писал по памяти.

    Проверил, уточняю - это модель Intel D3-S4610 480GB (SSDSC2KG480G801).

    Что касается записи большого файла... 

    Цель теста состоит в том, чтобы проверить как будет происходить запись с гипервизоров Hyper-V (резервные копии и экспорт вирт. машин) на сервер-хранилище резервных копий. Там как раз будут летать большие файлы... Необходимо уложиться приблизительно в 3-4 ночных часа, решить это c запасом можно за счет сети 10G. 

    Пока результат положительным назвать нельзя. Очень бы не хотелось организовывать хранилку на другой (не Windows) OS, так как это проходили, есть определенные подводные камни, от которых и хотим избавиться с переходом на Windows Server, тем более что лицензии у нас есть. Да и проще администрировать, если не плодить разнородные сущности.

    Провел тесты по копированию файла 150gb внутри сервера, с массива R10 на SSD на LSI HBA на массив R10 на HDD-дисках на контроллере LSI SAS 9271-8i. 

    Копирование начинается на скорости около 1gb/c - после копирования 50гб скорость резко падает до 300мб/с, копируется еще 50гб, потом скорость скачком увеличивается до 400мб/с и последние 50гб записываются с этой скоростью.

    Смотрю я на эти чудеса, и зреет у меня желание выдернуть RAID-контроллеры из серверов, и пробовать без них. Но для этого нужно доехать до месторасположения серверов.


    • Editado rapidon segunda-feira, 14 de dezembro de 2020 07:23
    segunda-feira, 14 de dezembro de 2020 07:06
  • На деле деле 60% от максимальной теоретической производительности - это очень даже неплохой результат. Если надо заметно больше - то видимо SSD которые вы изначально указали (вместо моделей 18 года на SATA) и несколько 10 гб интерфейсов в тиминге решат задачу.

    Если подобное поведение наблюдается и без сети, то редиректор тут явно не при чем. Может быть RAID контроллер действительно что то странное делает. Не понятно только куда падают первые 50 ГБ... У вас сколько памяти на данных серверах?


    This posting is provided "AS IS" with no warranties, and confers no rights.

    segunda-feira, 14 de dezembro de 2020 07:52
    Moderador
  • По 64гб на хост.

    Исходил из потребностей виртуалок. Думаете надо увеличивать для работы сети 10G? Тиминг средствами OS? Я боюсь, что тут не сетевые адаптеры виноваты, а что-то с настройкой OS, буферов и кэшей не так...  Думаете, если добавить в тиминг по два адаптера с каждой стороны, и каждый будет по реализовывать по 60%, то удастся утилизировать по максимуму все, на что способен массив SSD? Можно попробовать, но мне кажется узкое место не в сетевом адаптере....

    "....На деле деле 60% от максимальной теоретической производительности - это очень даже неплохой результат...."

    Может и неплохой.... Но провалы - я не думаю, что хорошо и нормально... явно что-то не так. Тем более, что в гугл не нахожу ничего подобного. Поэтому это скорее аномалия, чем нормальное поведение....

    Массив из SSD уже дает такую скорость чтения, чтобы ее хватало для загрузки порта сетевого адаптера.

    Сейчас необходимо ответить на вопрос - это железо или OS создает проблему?

    В драйверах сетевухи настроил только дуплекс, прерывания не трогал, да вообще более ничего там не трогал.

    Перепрошил матери под BIOS v3.2, крайний с сайта Supermicro. Прогулялся по настройкам биоса, особенно в части настроек процессора и шины. Процессор - полностью энергосбережение не отрубал, но performance поставил, убрав balanced между производительностью и энергосбережением. По шинам - все стоит в авто.... Честно говоря, без точного понимания, трогать настройки BIOS не очень хочется.

    RAID-контроллеры уже был готов выдрать из серверов для эксперимента (но пока сомневаюсь, что это что-то даст), но вот ехать в офис сейчас не разрешили, в связи с текущими ограничениями, поэтому все, что вижу - это удалено, через  RDP.

    Сбивает с толку iPerf3, при любом кол-ве потоков более 3 он загружает сетевой адаптер под завязку без каких-либо провалов в двух направлениях.

    Есть идея попробовать RAM-диск, как источник копируемого файла.

    Есть ли идеи - какие еще тесты провести, чтобы сузить поиск причины?








    • Editado rapidon terça-feira, 15 de dezembro de 2020 09:57
    terça-feira, 15 de dezembro de 2020 08:57
  • Мне кажется что просто массив не способен записывать с такой скоростью. Скорее всего первые ~50 ГБ сваливаются в ваши 64 ГБ RAM (или SLC кэш в накопителе) со скоростью сетевого интерфейса, дальше все останавливается и начинает сливаться в SSD с какой то меньшей скоростью. Никаких "провалов" по факту нет, просто накопители не могут.

    SSD на записи могут вести себя очень интересно, например первые несколько ГБ записывают с очень высокой скоростью, на SATA часто ограниченной интерфейсом. А дальше скорость записи сильно падает, в 3-5 раз и даже более. Если у вас 3 накопителя в группе в половине зеркала, то на чтение данная конструкция будет выдавать, скажем, 1.2-1.5 ГБ/с. Что не сильно быстрее сетевого интерфейса. А на запись может быть заметно меньше. Может быть те самые 600 мб/с которые получаются по факту.

    Для тестов накопителей существует много инструментов, никаких РАМ дисков не требуется. Найдите статью с обзором одного из ССД и используйте инструменты которые там указаны. Например, поиск "Обзор накопителя Intel SSD 540s" найдет пример. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    terça-feira, 15 de dezembro de 2020 17:21
    Moderador
  • "....Если у вас 3 накопителя в группе в половине зеркала, то на чтение данная конструкция будет выдавать, скажем, 1.2-1.5 ГБ/с. ...."

    Насколько я понимаю, если взять 6 накопителей и собрать их в Pool на основе Mirror, то на самом деле они будут собраны попарно в 3 зеркала, а эти зеркала будут собраны чередованием в единое пространство. Полагаю, что да макс. скорость массива должна быть утроенному значению одиночного диска.

    То есть вы считаете, что на принимающем сервере,  возникает проблема по записи на массив SSD, так как его быстрый кэш (SLC) значительно меньше емкости самого накопителя. При этом сервер, отдающий данные в этот момент не создает ограничений. Правильно я понял?

    Но как быть с тем, что когда я забираю данные с сетевой шары на SSD-массиве, на локальный такой же массив? Ведь копирование идет без каких-либо провалов с максимальной скоростью (980-1030 mb/s)??

    Чтобы проверить вашу мысль "грубой силой" я установил на один сервер RAM-disk от StarWind размером 40гб, отформатировал его в NTFS с параметрами по умолчанию, расшарил его, и сделал попытку записать на эту шару архив размером 30гб, предварительно проверив, как он пишется на SSD-массив (пишется с провалами, просто их меньше, на этом отрезке в 30gb - 2-3 провала, а скорость по хронометражу та же - 600-650мб/с).

    При записи файла через сеть 10G на RAM-disk запись таки имела провалы, но они были узкие, а хронометраж процесса копирования показал, что файл записывался со скоростью 900мб/с. Пока я не понимаю как это интерпретировать.

    То есть в сухом остатке:

    - появление более скоростного "приемника" привело к увеличению скорости копирования.

    - провалы не исчезли, но изменился их временной размер, могу лишь сказать что не более секунды, на графике характерный "клык".

    - В обратном направлении (с шары на локальный диск) провалов нет без всяких рам-дисков.

    По поводу инструментов для тестирования из материала по Intel SSD 540s вы имели ввиду iometer?




    • Editado rapidon quarta-feira, 16 de dezembro de 2020 06:21
    terça-feira, 15 de dezembro de 2020 23:33
  • Утроение скорости на трех дисках получается только в мечтах. Всегда есть какие то накладные расходы. Думаю если выйдет 80% то это будет отличным результатом.

    Да, это интересный вопрос. Уверены что это не ошибка эксперимента? 

    Провалы видимо возникают при переполнении буфера/кэша. Очевидно что в случае РАМ диска (которые, кстати, совершенно бесполезны в современных условиях) буфер не нужен, но ОС об этом не знает.

    Кстати, не ясно зачем были нужны хлопоты с рам диском, ведь есть ну очень быстрое устройство nul

    copy /b \\server\share\file.ext nul 

    Да, например иометер. Измерьте, посмотрите сколько там у вас массив реально тянет на запись и чтение. 

    Так же еще раз предложу не терять времени: у вас все работает нормально. Добиться 100% теоретической скорости обычно просто невозможно. Если скорость недостаточна, то следует использовать железо с более высоким теоретическим пределом.


    This posting is provided "AS IS" with no warranties, and confers no rights.

    quarta-feira, 16 de dezembro de 2020 07:56
    Moderador
  • "Да, это интересный вопрос. Уверены что это не ошибка эксперимента?"

    А как тут можно ошибиться? Может я неверно интерпретирую результаты, в чем-то заблуждаюсь? Но пока не могу понять в чем. 

    Еще раз... Переносим фокус на srv1. 

    Копируем: 

    copy /b g:\file-test.vhdx \\srv2\Test-R10\file-test.vhdx

    Скорость 650мб/с. Провалы имеются - по мониторингу в диспетчере задач.

    Фокус остается по-прежнему на srv1Забираем файл с шары на srv2 и копируем в nul на srv1: 

    copy /b  \\srv2\Test-R10\file-test.vhdx nul 

    Получаем 1089mb/c, без провалов, можно сказать ровная линия копирования. Можно копировать не в nul, а  на ssd-массив - результаты хуже, но не фатально, разница не превышает 100мб/с. Но стоит перейти на сервер srv2 и иницировать ту же операцию, в том же направлении ,  то увидим ту же самую проблему.

    Время копирования различается! Проверено файлами размером 30, 50, 150гб.

    Меняем фокус на srv2. Проделываем такие же команды,т.к. имена файлов, шар одинаковые, отличие лишь в имени сервера в команде. Имеем точно такие же результаты.

    Иными словами, на обоих серверах абсолютно одинаковые SSD массивы выступающие и "источниками", и "приемниками". Но их работа зависит от направления копирования, если мы производим копирование в обеих направлениях находясь на одном сервере, что обычно и бывает по жизни. Для меня же более важным представляется именно запись на сетевую шару, где и проявляются проблемы.

    Если запись на шару производить каждый раз перескакивая на рабочий стол сервера откуда эта запись инициируется - будем видеть одинаковую картину с падением скорости и провалами.

    Это можно было бы списать на, скажем, некоторые свойства отображения информации мониторингом OS, но на лицо разница во времени копирования... 

    Поэтому я не могу согласиться с тем, что "все работает нормально".

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

    Почему запись на один и тот же массив ведет себя по-разному в зависимости от места инициации процесса? В чем различие работы OS в зависимости  от того, где инициирован процесс, от направления копирования?  

    • Editado rapidon quarta-feira, 16 de dezembro de 2020 18:12
    quarta-feira, 16 de dezembro de 2020 16:40
  • "Да, это интересный вопрос. Уверены что это не ошибка эксперимента?"

    А как тут можно ошибиться? Еще раз:

    Фокус на srv1. 

    Копируем: 

    copy \b g:\file-test.vhdx \\srv2\Test-R10\file-test.vhdx


    Ну, например, можно перепутать слэши в команде, вместо /b напечатать \b. :)

    Если серьезно, то разница в том что в случае записи на удаленный сервер этот удаленный сервер не имеет прямого доступа к ПК который осуществляет запись. Это может влиять на подтверждение о завершении записи блоков. В случае записи на удаленный сервер это подтверждение идет по сети с определенной задержкой. Во втором случае это подтверждение локально, без задержки. Не знаю будет ли по факту разница, но сравните потоки данных в обратном направлении для этих двух вариантов.

    В любом случае, можете конечно продолжать изыскания, но я думаю загадка останется не раскрытой. Уж очень много разных факторов от специфики работы ОС до взаимодействия железа. 


    This posting is provided "AS IS" with no warranties, and confers no rights.

    quarta-feira, 16 de dezembro de 2020 17:44
    Moderador
  • Раздумывая сегодня над тем, что написал выше, взял другую железяку со склада...

    Это сервер на m/b Intel s1200V3RPL c Xeon 1240 v3, 32 гб памяти, 6 х SATA HDD 6tb, X520DA2 (PCI-e 3.0 x8)

    Быстренько вонзил туда TrueNAS 12, создал ZFS pool из трех зеркал (тот же эквивалент R10) и с srv1 начал писать те же файлы на сетевую шару SMB на этом пуле.

    Результат 600мб/с, ровная линия, никаких провалов. Хронометраж подтверждает эту скорость на файлах 30, 50, 150 гб. Трафик сетевого адаптера в диспетчере задач - почти ровная, слегка волнистая линия.

    Теперь хочу снести Win Srv 2019 на srv2 и воткнуть тот же TrueNAS (бывший FreeNAS) и попробовать массивы из 6 x ssd и 8 x SATA HDD.....

    quarta-feira, 16 de dezembro de 2020 18:11
  • Раздумывая сегодня над тем, что написал выше, взял другую железяку со склада...

    Это сервер на m/b Intel s1200V3RPL c Xeon 1240 v3, 32 гб памяти, 6 х SATA HDD 6tb, X520DA2 (PCI-e 3.0 x8)

    Быстренько вонзил туда TrueNAS 12, создал ZFS pool из трех зеркал (тот же эквивалент R10) и с srv1 начал писать те же файлы на сетевую шару SMB на этом пуле.

    Результат 600мб/с, ровная линия, никаких провалов. Хронометраж подтверждает эту скорость на файлах 30, 50, 150 гб. Трафик сетевого адаптера в диспетчере задач - почти ровная, слегка волнистая линия.

    Теперь хочу снести Win Srv 2019 на srv2 и воткнуть тот же TrueNAS (бывший FreeNAS) и попробовать массивы из 6 x ssd и 8 x SATA HDD.....

    То есть выходит в одном случае вы получили скорость 600 мб/с, а в другом случае 600 мб/с? 

    This posting is provided "AS IS" with no warranties, and confers no rights.

    quarta-feira, 16 de dezembro de 2020 19:32
    Moderador
  • Илья! мне очень ценна ваша помощь, но зачем путать теплое с мягким? ))

    В одном случае я получил скорость 650мб/с как усредненную величину, выведенную на основе промера длительности процесса и вычисления скорости. То есть график копирования (сетевухи в диспетчере) - это по сути прямоугольные "импульсы", меандр, когда есть пачка отправленных данных со скоростью 1,03гб/с, потом провал до нуля, потом снова пачка. 

    Но был еще массив на RAID контроллере - те же 6 дисков SATA HDD. Помните? и там тоже просадки, и скорость 600мб (первые 50гб), потом скачком - 300, потом скачком 400 и также провалы на сетевухе.  

    Ну и не забудьте про поставленный вопрос про "направления" копирования... почему SSD-массив  в одном случае тупит,  а в другом прет как танк - и оба случая это в режиме  записи....  см. выше.

    В случае же TrueNAS никаких провалов нет, нет никаких искажений представляемого в мониторинге трафика, хотя как мы понимаем сетевуха недогружена, диска не хватает.... Но есть ровные графики, есть индикация скорости в 600мб/с и есть хронометраж, который дает ту же скорость. Все совпадает, а значит похоже на правду.

    В случае же "провалов" что-то не бьется, и странные графики и показываемые скорости, и хронометраж, который дает скорость 65% от обозначенной виндой.

    Поэтому хочу попробовать на srv2 воткнуть TrueNAS - там диски "поновее" и 8 штук возможно достанут до 800-900мб/с, догрузят сетевуху.... и посмотрим появятся провалы? Как себя поведет железо, так же или совсем по другому...

    Еще один момент вспомнился. Сейчас на MS лежат 2 дистрибутива WS2019, апрельский и декабрьский, кажется...  У меня установлены апрельские, естественно со всеми обновами. Но все-таки это имеет какое-то значение? возможно надо проинсталлировать декабрьский

    Тут я читал про проблемы 19-го с тормозами на файловых операциях... Вот интересно, эти болячки уже вылечены? 

    А киса - роскошная на фото... ) 



    • Editado rapidon sábado, 19 de dezembro de 2020 14:01
    quarta-feira, 16 de dezembro de 2020 22:28
  • 1. Нашел интересную тему 

    https://community.spiceworks.com/topic/2225989-server-2019-network-performance?page=1

    Пока ее читаю и осмысливаю, актуальна ли она на сегодняшний день...

    2. Провел тестирование по размеру файла. Т.е. решил найти ту величину при превышении которой, начинаются "провалы" по записи на сетевую шару на втором WS2019 (который в будущем должен выступать как файловый сервер хранения резервных копий).

    Так вот, в моем случае если файл не превышает размер 5GB, то провалов не возникает, если превышает  5,5GB, то при первичном копировании возникает единственный провал в конце процесса копирования, прямо перед его завершением. Если делать последующие повторные попытки - провал не появляется. Если файл превышает размер 6,5GB, то единственный провал гарантировано появляется в конце процесса копирования при любой попытке.  

    Приведу ссылку на ролик, где видно, как происходит процесс копирования.

    https://yadi.sk/i/qQ_hSm9tgvoqVg 

    размер ролика - 118мб!

    На ролике я копирую файл 20gb в двух направлениях, видно что происходит.

    После просмотра напишите пожалуйста ваше мнение, нормальное это поведение или нет. Спасибо!




    • Editado rapidon sábado, 19 de dezembro de 2020 12:42
    quinta-feira, 17 de dezembro de 2020 22:51