Скорость копирования по сети

[MaxX]

Добрый день.
Долго думал  куда отправить пост: в сети или дисковые массивы - решил сюда

Ситуация такова.
Есть 3 сервера: S1 - база,  S2 - бэкап, S3 - тестовая машинка, используется для сранения. На всех серверах установлена Win2003 Server R2

Стоит задача максимально-быстрого (на данном оборудовании) копирования данных с S1 на S2.

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

На S1 и S3  - интегрированные Intel PRO 1000 EB, драйвера последние и одинаковые.
На S2 -  Intel PRO 1000 XT

На каждом из серверов есть по массиву: S1A1,  S2A1, S3A1

Тесты Iometer (S1A1 и S3A1 на последовательное чтение, S2A1 - последовательную запись)  демонстрируют очень понятные и адекватные оборудованию цифры.  Конкретные цифры, если будет надо приведу позже. По ним ресурсов у дисковой системы достаточно для обеспечения желаемой скорости передачи данных.


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

При копировании данных с  S1A1 на S2A1 в perfomance monitor`е  наблюдаю такую картину:

скорость записи на S2A1 - равномерная пила 10-20 МБайт/Сек
длина очереди на запись (queue length) - равномерная пила от 15 до 30 (!!!)

скорость передачи данных по сети - на первом этапе (неколько секунд) ~40 МБайт/сек, далее ещё несколько секунд ~20 МБайт/сек (я так понимаю забиваются все возможные буферы), далее пила 0-15 МБайт/сек

И совершенно другая картина в следующем тесте - копируем данные с S3A1 на S2A1
скорость записи на S2A1 - достаточно равномерная ~40 МБайт/Сек
длина очереди на запись (queue length) - почти постоянна и равна 2 (!!!)
скорость передачи данных по сети постоянная ~40 МБайт/Сек.

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

Описание железок если надо приведу, но что-то мне подсказывает что ковырятся надо в настройках ОС.

Спасибо
Макс

[VladimirR]

Интересны следующие ваши параметры:
"длина очереди на запись (queue length) - равномерная пила от 15 до 30 (!!!)
..., далее пила 0-15 МБайт/сек"
1-ый говорит о том, что не справляется дисковая подсистема. (Желательно, чтобы очередь не превышала 4)
2-ой - говорит о работе протокола TCP-IP: установка соединения на максимальной скорости, и даленейший спад из-за потерь пакетов, а вот почему пакеты теряются ??,- предположу, что из-за очереди на дисковую.
Предположу, что пинги любыми размерами пакетов пройдут нормально в обе стороны.

[MaxX]

1-ый говорит о том, что не справляется дисковая подсистема. (Желательно, чтобы очередь не превышала 4)
2-ой - говорит о работе протокола TCP-IP: установка соединения на максимальной скорости, и даленейший спад из-за потерь пакетов, а вот почему пакеты теряются ??,- предположу, что из-за очереди на дисковую.
Предположу, что пинги любыми размерами пакетов пройдут нормально в обе стороны.

Всё верно...  и пинги ходят без проблем любые...
На самом деле в сети картина ещё интересней... Процесс длительный (10GB как-никак), и вот с течением времени, вероятно когда данные из кешей сбрасываются на диск, скорость в сети снова поднимается до "уровня 2"... а через некоторое время опять падает до "уровня 3".... И такие волны присутствуют на протяжении всего процесса...

Т.е.  ситуация в сети достаточно прозрачна, а вот откуда очередь на запись в дисковой сиситеме - загадка...

[and3008]

После прочтения этого:
https://thesource.ofallevil.com/technet ... x?mfr=true

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

Проведите эксперимент с остановленной и выгруженной из памяти СУБД. Вероятно результаты будут совсем другие.

Про фрагментацию тоже не забудьте.

[MaxX]

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

Спасибо почитаю...
Но думаю дело не в банальной нагрузке на S1.
Нагрузка на S1 не объясняет возникновение очереди на запись на S2.
Более того нагрузка на S1 практически не сказывается на тестах Iometr и на локальном копировании между разными массивами на S1.

[MaxX]

Вести с полей... свежая информация...

1. На контроллере S2A1 (куда производится запись - 3WARE 9550SX-12, RAID5 4 шт ST3750640NS) обновил firmware - на тестах не сказалось.

2. На нём же (S2A1) в Iometer увидел интересную картину.
паттерн 64К 100% write 100% sequential

а) 1 worker,  # of outstandimg IO - 1
скорость записи 150 МБайт/сек, очередь чуть меньше  1

б) 1 worker и увеличиваю # of outstandimg IO
скорость записи увеличивается до ~200МБайт/сек, очередь увеличивается в сооответствии с # of outstandimg IO

в) 2 workers и # of outstandimg IO на каждый worker  - 1
скорость - пила около 150 МБайт, очередь 2

г) 3 workers (на сервере 2 CPU) , # of outstandimg IO на каждый worker  - 1
очередь соответствует сумме  # of outstandimg IO  
скорость записи падает на  порядок!!! (в десятичной системе )

как интерпретировать ситуацию с 3 (и более) worker-ами не знаю, но поведение странное

3. Самое интересное
Как оказалось тесты я проводил не совсем корректные  :-(
И отличие заключается не в серверах, а в том откуда запущен процесс копирования.
Т.е.
если копировать данные с S1A1 на S2A2 и процесс  этот запускать через explorer на S1, то возникает та самая странная картина с ненормального размера очередью на запись на S2A2.

если копировать данные с S1A1 на S2A2, но процесс запускать на S2, то возникает благостная картина с нормальной очередью на запись и вменяемой скоростью записи.

Для сервера S3 всё картина соответствует S1.

[abc]

А на S1 система случаем не SATA стоит?

[MaxX]

А на S1 система случаем не SATA стоит?

Нет, S1A1 320-2х RAID5 5 x Seagate 146GB SCSI
На S1 есть  ещё один массив (на нём сейчас нагрузки нет), картина с очередью на запись S2A1 такая же.

[abc]

Ну тогда гипотеза умирает...
Хотя проверьте все-таки, не тормозит ли запись на логический диск, где размещен своп.

[MaxX]

Крыша едет не спеша тихо шифером шурша... это я про себя

Итак, пробовал установить SP2, менял драйверы сетевых карт, их настройки и много чего ещё.
Активности в свопфайле на машине с которой происходит копирование нет.

Изменений в поведении нет.

Итого, при копировании одного и тогоже файла с S3A1 на S2A1 при инициировании этого процесса с S2 картина в perfomance monitor`е адекватна, а вот при инициировании этого процесса с S3 - очередь на запись на S2A1 и падение скорости записи.
Картинка где это всё вместе нарисовано прилагается.
Есть у кого идеи что это может быть за хрень?

PS. кстати там на картинке желтенькое - это усреднённое количество килобайт на оду операцию записи. Так вот в первом случае оно четко равняется 64К, а во втором неуверенно болтается около 55К... странно всё это

[and3008]

Ну если подойти чисто академически, то получается, что косяк в подсистеме, обеспечивающей копирование по сети, а именно то, что обеспечивает работу SMB. А может и сетевая подсистема мудрит...

Дабы в этому убедиться попробуй копирнуть большой файл по FTP или TFTP. Тогда будет более ясно кто виноват, сеть или все же диски.

[abc]

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

[MaxX]

Ну если подойти чисто академически, то получается, что косяк в подсистеме, обеспечивающей копирование по сети, а именно то, что обеспечивает работу SMB.

Ура! Человеческий разум одержал верх над бездушной железякой

Прошерстив MS KB по SMB нашел несколько статей, напрямую к моему косяку не относящихся, но всё же описывающие схожие ситуации.
Итак, на S2 был создан волшебный ключик

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters
  Value Name: SizReqBuf
  Data Type: REG_DWORD
  Data: 512 - 65535
  Default: 4356

Не мудрствуя лукаво поставил по максимуму
Теперь картина одинаковая независимо от того с какого сервера инициировать процесс копирования, очередь 3-4. Правда скорость копирования с S1->S2 всё ещё маловата (и ощутимо ниже) чем S3->S2, но с очередью на запись всё в порядке, а со скоростью буду разбираться дальше.


P.S. со свопигом было всё в порядке, в том смысле что это был не он, FTP тоже работал хорошо, 40MB/сек выдавал стабильно, дополнительной активности (ни чтения ни записи) на S2A2 тоже небыло. Удивил ntbackup - как он копирует данные вообще непонятно, 10МБ/сек и ни грамма больше.

Спасибо всем участникам дискуссии, но что-то мне подсказывает что это был не последний вопрос на эту тему

PPS. Кстати, а сколько МБ/сек. реально можно прокачать по гигабитной сети? не в теории а напрактике чего удавалось достичь?

[Tert]

MaxX
Спасибо за информацию. Надо это в FAQ занести.

PPS. Кстати, а сколько МБ/сек. реально можно прокачать по гигабитной сети? не в теории а напрактике чего удавалось достичь?

На практике удавалось достичь около 200-220 МБ/c (в дуплексном режиме).

[and3008]

Если уж увеличили размер буфера у SMB, то увеличьте и размер окна у TCP/IP. На известном вам сайте найдете как это делается, сам подсказывать не буду, ибо лень искать.
Там же подсказки по тюнингу стека TCP/IP увидите.

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