Скорость копирования по сети
Модераторы: Trinity admin`s, Free-lance moderator`s
Скорость копирования по сети
Добрый день.
Долго думал куда отправить пост: в сети или дисковые массивы - решил сюда
Ситуация такова.
Есть 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?
Описание железок если надо приведу, но что-то мне подсказывает что ковырятся надо в настройках ОС.
Спасибо
Макс
Долго думал куда отправить пост: в сети или дисковые массивы - решил сюда
Ситуация такова.
Есть 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?
Описание железок если надо приведу, но что-то мне подсказывает что ковырятся надо в настройках ОС.
Спасибо
Макс
- Вложения
-
- s1_a1-s2_a1_hdd_write.png
- тест 1, диски: синее - запись, голубенькое - очередь (не забудьте про масштабные коэффициенты :-)
- (27.31 КБ) 310 скачиваний
-
- s1_a1-s2_a1_net.png
- тест 1, сеть: желтенькое- скорость приёма
- (26.76 КБ) 314 скачиваний
-
- s3_a1-s2_a1_hdd_write.png
- тест 2, диски: синее - запись, голубенькое - очередь
- (25.27 КБ) 330 скачиваний
- VladimirR
- Сотрудник Тринити
- Сообщения: 160
- Зарегистрирован: 26 мар 2007, 18:22
- Откуда: St.-Petersburg
- Контактная информация:
Интересны следующие ваши параметры:
"длина очереди на запись (queue length) - равномерная пила от 15 до 30 (!!!)
..., далее пила 0-15 МБайт/сек"
1-ый говорит о том, что не справляется дисковая подсистема. (Желательно, чтобы очередь не превышала 4)
2-ой - говорит о работе протокола TCP-IP: установка соединения на максимальной скорости, и даленейший спад из-за потерь пакетов, а вот почему пакеты теряются ??,- предположу, что из-за очереди на дисковую.
Предположу, что пинги любыми размерами пакетов пройдут нормально в обе стороны.
"длина очереди на запись (queue length) - равномерная пила от 15 до 30 (!!!)
..., далее пила 0-15 МБайт/сек"
1-ый говорит о том, что не справляется дисковая подсистема. (Желательно, чтобы очередь не превышала 4)
2-ой - говорит о работе протокола TCP-IP: установка соединения на максимальной скорости, и даленейший спад из-за потерь пакетов, а вот почему пакеты теряются ??,- предположу, что из-за очереди на дисковую.
Предположу, что пинги любыми размерами пакетов пройдут нормально в обе стороны.
Всё верно... и пинги ходят без проблем любые...VladimirR писал(а):1-ый говорит о том, что не справляется дисковая подсистема. (Желательно, чтобы очередь не превышала 4)
2-ой - говорит о работе протокола TCP-IP: установка соединения на максимальной скорости, и даленейший спад из-за потерь пакетов, а вот почему пакеты теряются ??,- предположу, что из-за очереди на дисковую.
Предположу, что пинги любыми размерами пакетов пройдут нормально в обе стороны.
На самом деле в сети картина ещё интересней... Процесс длительный (10GB как-никак), и вот с течением времени, вероятно когда данные из кешей сбрасываются на диск, скорость в сети снова поднимается до "уровня 2"... а через некоторое время опять падает до "уровня 3".... И такие волны присутствуют на протяжении всего процесса...
Т.е. ситуация в сети достаточно прозрачна, а вот откуда очередь на запись в дисковой сиситеме - загадка...
После прочтения этого:
https://thesource.ofallevil.com/technet ... x?mfr=true
смею предположить, что тормоза на сервере S1, там ведь база данных. И памяти небось она скушала порядочно. Соответственно часть системного кэша уползла в своп и вот вам результат.
Проведите эксперимент с остановленной и выгруженной из памяти СУБД. Вероятно результаты будут совсем другие.
Про фрагментацию тоже не забудьте.
https://thesource.ofallevil.com/technet ... x?mfr=true
смею предположить, что тормоза на сервере S1, там ведь база данных. И памяти небось она скушала порядочно. Соответственно часть системного кэша уползла в своп и вот вам результат.
Проведите эксперимент с остановленной и выгруженной из памяти СУБД. Вероятно результаты будут совсем другие.
Про фрагментацию тоже не забудьте.
Спасибо почитаю...and3008 писал(а):смею предположить, что тормоза на сервере S1, там ведь база данных. И памяти небось она скушала порядочно. Соответственно часть системного кэша уползла в своп и вот вам результат.
Но думаю дело не в банальной нагрузке на S1.
Нагрузка на S1 не объясняет возникновение очереди на запись на S2.
Более того нагрузка на S1 практически не сказывается на тестах Iometr и на локальном копировании между разными массивами на S1.
Вести с полей... свежая информация...
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.
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.
Крыша едет не спеша тихо шифером шурша... это я про себя
Итак, пробовал установить SP2, менял драйверы сетевых карт, их настройки и много чего ещё.
Активности в свопфайле на машине с которой происходит копирование нет.
Изменений в поведении нет.
Итого, при копировании одного и тогоже файла с S3A1 на S2A1 при инициировании этого процесса с S2 картина в perfomance monitor`е адекватна, а вот при инициировании этого процесса с S3 - очередь на запись на S2A1 и падение скорости записи.
Картинка где это всё вместе нарисовано прилагается.
Есть у кого идеи что это может быть за хрень?
PS. кстати там на картинке желтенькое - это усреднённое количество килобайт на оду операцию записи. Так вот в первом случае оно четко равняется 64К, а во втором неуверенно болтается около 55К... странно всё это
Итак, пробовал установить SP2, менял драйверы сетевых карт, их настройки и много чего ещё.
Активности в свопфайле на машине с которой происходит копирование нет.
Изменений в поведении нет.
Итого, при копировании одного и тогоже файла с S3A1 на S2A1 при инициировании этого процесса с S2 картина в perfomance monitor`е адекватна, а вот при инициировании этого процесса с S3 - очередь на запись на S2A1 и падение скорости записи.
Картинка где это всё вместе нарисовано прилагается.
Есть у кого идеи что это может быть за хрень?
PS. кстати там на картинке желтенькое - это усреднённое количество килобайт на оду операцию записи. Так вот в первом случае оно четко равняется 64К, а во втором неуверенно болтается около 55К... странно всё это
- Вложения
-
- s3a1-s2a1_hdd.png
- (29.66 КБ) 314 скачиваний
Ну если подойти чисто академически, то получается, что косяк в подсистеме, обеспечивающей копирование по сети, а именно то, что обеспечивает работу SMB. А может и сетевая подсистема мудрит...
Дабы в этому убедиться попробуй копирнуть большой файл по FTP или TFTP. Тогда будет более ясно кто виноват, сеть или все же диски.
Дабы в этому убедиться попробуй копирнуть большой файл по FTP или TFTP. Тогда будет более ясно кто виноват, сеть или все же диски.
Ура! Человеческий разум одержал верх над бездушной железякойand3008 писал(а):Ну если подойти чисто академически, то получается, что косяк в подсистеме, обеспечивающей копирование по сети, а именно то, что обеспечивает работу 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. Кстати, а сколько МБ/сек. реально можно прокачать по гигабитной сети? не в теории а напрактике чего удавалось достичь?
Если уж увеличили размер буфера у SMB, то увеличьте и размер окна у TCP/IP. На известном вам сайте найдете как это делается, сам подсказывать не буду, ибо лень искать.
Там же подсказки по тюнингу стека TCP/IP увидите.
Но помните, что тюнинг - это всегда искуство. Что-то поменяли и результаты могут быть прямо противоположные.
Там же подсказки по тюнингу стека TCP/IP увидите.
Но помните, что тюнинг - это всегда искуство. Что-то поменяли и результаты могут быть прямо противоположные.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 22 гостя