LINUX.ORG.RU

software raid тормозит


2

4

хай всем есть система на сокет 2011, к ней через софт рейд1 в убунте подключены два винта. скорость работы с каждым из винтов по hdparm-у - 140 мб/с. скорость записи на рейд1 - 60мб/с. я так понимаю тут без аппаратного контроллера никак? ps. памяти 32гб, винты рапторы 600гиг, подключены через sata3 порты.



Последнее исправление: ioan (всего исправлений: 2)

Ты правда думаешь, что 60 мб\с может быть существенной нагрузкой для модуля ядра? Вероятнее всего тонкое место где-то в другом месте.

azure ★★
()

скорость работы с каждым из винтов по hdparm-у - 140 мб/с

Это чтение?

скорость записи на рейд1 - 60мб/с

Как измерено?

GotF ★★★★★
()
Ответ на: комментарий от azure

для модуля ядра нет. чипсет на мамке - intel x79. мне интерестно какую максимальную скорость может выжать sata контроллер. может узкое место в нём? я уже тыкал в разные разъёмы (на мамке три разных контроллера), но результат особо не поменялся.

ioan
() автор топика
Ответ на: комментарий от GotF

140мб/с чтение, 60мб/с измерялось записью 10гб файла с помощью dd if=/dev/zero, а также просто копированием файла с одного рейда на другой (на компе два рейда1 по два винта).

ioan
() автор топика
Ответ на: комментарий от ioan

dd if=/dev/zero

Попробуй для начала с bs=10M, а лучше pv. Размер сектора в 512 байт плохо подходит для таких измерений.

GotF ★★★★★
()
Ответ на: комментарий от ioan

Политика записи на soft-рейд round-robin?

На всякий случай: проверь поверхность каждого винчестера на BAD-блоки.

iZEN ★★★★★
()
Ответ на: комментарий от ioan

А с чего ты взял, что скорость записи будет равна скорости чтения? Она обычно ниже. Правда, я бы ожидал около 100 Мб/с на запись при 120-140 на чтение, но это не обязательно должно быть так.

Попробуй таким же способом замерить скорость записи на отдельный диск.

GotF ★★★★★
()
Ответ на: комментарий от GotF

проблемы начались после того как поменял мамку с p67 чипсета на x79. на p67-ом hdparm выдавал на чтение 155мб/с, на 20мб/с больше. запись я тогда не мерял, но на глаз всё работало шустрее.

ioan
() автор топика
Ответ на: комментарий от ioan

скорость чтения файла через dd 141мб/с как и должно быть. надо будет попробовать отключить журнал на ext4.

ioan
() автор топика

Блин, ну сколько можно?

1. hdparm неадекватно показывает скорость работы soft-raid

2. у обычных дисков имеют скорость чтения-записи в начале и конце отличается почти в 2 раза

3. софт-рейд1 это по-сути только multipath, с контролем целостности

4. на скорость существенно влияют такие вещи на scheduler, readahead

Решение:

1. для оценки линейной скорости использовать time sh -c"dd if=/dev/zero of=...&& sync" с объемом в два раза больше оперативки

2. грамотно разбить диск, выделив примерно 1/3 (в начале диска) для быстрой работы с данными. В этом случае, даже в конце раздела скорость будет близка к максимальной. Не забыть про выравнивание.

3. делать mdadm --create --level 10 -p f2 --raid-devices=2 /dev/sd[ab]1 # это по-сути raid1, только не симетричный: копии чанка будут в конце (опция «f» = far) раздела на втором винте, поэтому запись будет равна минимальной по скорости, а чтение будет удвоено (с raid10 ускорение у mdadm есть).

4. например (мои оптимальные значения) echo deadline > /sys/block/sda/scheduler ; echo deadline > /sys/block/sdb/scheduler ; blockdev --setra 2048 /dev/md1

soomrack ★★★★
()
Ответ на: комментарий от ioan

скорость чтения файла через dd 141мб/с как и должно быть. надо будет попробовать отключить журнал на ext4.

Cущественное падение скорости у ext4 на запись наблюдается только с mount ... -o data=journal, падение в 2 раза. При data=writeback или data=ordered падение скорости записи незначительное. На скорость чтения у ext4 очень хорошо влияют параметры монтирования: mount ... -o inode_readahead_blk=4096,commit=60,nobarrier,noatime,noacl,nouser_xattr

soomrack ★★★★
()
Ответ на: комментарий от GotF

Зачем давать вредные советы? Сбой может случиться всегда.

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

soomrack ★★★★
()
Ответ на: комментарий от soomrack

делать mdadm --create --level 10 -p f2 --raid-devices=2 /dev/sd[ab]1

Побочных эффектов нет? Кажется, где-то видел критику такого решения. Ну и с RAID1 удвоенную скорость получить можно — должно быть более одного потока чтения.

GotF ★★★★★
()
Ответ на: комментарий от GotF

Побочных эффектов нет?

Пока не сталкивался.

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

К сожалению, в два потока тоже не удвоенная скорость получается. Если потоков много, то тогда да, наверное будет ускорение близкое к удвоенному, но и это вряд ли, в таких случаю уже будет возобладать случайное чтение, с соотв. падением скорости... Т.е. свои 2x140MB/s не увидеть.

soomrack ★★★★
()
Ответ на: комментарий от ioan

измерялось записью 10гб файла с помощью

так, стоп. мы рейд тестируем, или ФС? почему бы не сделать dd if=/dev/zero of=/dev/md0?

redixin ★★★★
()
Ответ на: комментарий от GotF

Побочных эффектов нет? Кажется, где-то видел критику такого решения. Ну и с RAID1 удвоенную скорость получить можно — должно быть более одного потока чтения.

Критика скорее всего простая:

1. grub на него не установить (ибо это не зеркальный raid)

2. если диски под такой raid выдаются целиком, то скорость записи будет равна минимальной на диске, т.е. в случае ТС, это как раз около 80MB/s (при максимальной на одном диске 140MB/s) — за счет падения скорости на внутренних дорожках.

soomrack ★★★★
()
Ответ на: комментарий от soomrack

Пока не сталкивался.

Хорошо, надо будет попробовать для интереса.

К сожалению, в два потока тоже не удвоенная скорость получается.

Ну, вот таким сильно искусственным методом практически получается:

~ # (cat /dev/md0 & cat /dev/md0) | pv > /dev/null 
29GB 0:00:26 [ 266MB/s] [                        <=>                        ]

:)

GotF ★★★★★
()
Ответ на: комментарий от GotF

Ну, вот таким сильно искусственным методом практически получается:

А тут удвоенная скорость не от кеширования ли? :)

soomrack ★★★★
()
Ответ на: комментарий от soomrack

А тут удвоенная скорость не от кеширования ли? :)

Нет, проверял после

sync; sync; sync
sysctl vm.drop_caches=3

И вроде бы при чтении непосредственно с md0 файловый кэш не должен использоваться?

GotF ★★★★★
()
Ответ на: комментарий от GotF

И вроде бы при чтении непосредственно с md0 файловый кэш не должен использоваться?

Думаю, что должен, ибо «все есть файл», но точно не знаю.

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

soomrack ★★★★
()
Ответ на: комментарий от GotF

Возможно, а у меня согласно iostat -d 2 -x чтение одного файла пыталось делаться то с одного диска то с другого. И из-за подобных «перескоков» и наблюдалось падение производительности, даже при чтении двух файлов.

soomrack ★★★★
()
Ответ на: комментарий от ioan

для модуля ядра нет. чипсет на мамке - intel x79. мне интерестно какую максимальную скорость может выжать sata контроллер. может узкое место в нём? я уже тыкал в разные разъёмы (на мамке три разных контроллера), но результат особо не поменялся.

Если мне не изменяет память, sata3 это 6Gb/s ~ 768MB/s, разумеется в биосе для него не должно стоять режимов совместитмости, ide, raid и пр. хрени.

soomrack ★★★★
()
Ответ на: комментарий от GotF

Кажется, где-то видел критику такого решения.

Возможно, у меня. [Soft] RAID5 or RAID10 для сервера? (комментарий) - тут я сам дошел до упомянутого варианта, через время начал его использовать, но недавно таки перешел на обычный RAID1 - линейное чтение одного файла с большой скоростью мне не нужно, а на нескольких потоках RAID1 тоже дает прирост.

А по RAID10 - да, в целом все хорошо, но когда делается какая-то операция синхронно для всех дисков (например, проверка RAID'а, перестройка и т.п.), на второй диск нагрузка оказывается сильно выше (=> выше износ механических частей), а скорость ребилда меньше. Причем, повышенную нагрузку я наблюдал даже при операциях поиска в большом каталоге. Решил не рисковать и избавился от RAID10 в таком варианте.

YAR ★★★★★
()
Ответ на: комментарий от YAR

А по RAID10 - да, в целом все хорошо, но когда делается какая-то операция синхронно для всех дисков (например, проверка RAID'а, перестройка и т.п.), на второй диск нагрузка оказывается сильно выше (=> выше износ механических частей), а скорость ребилда меньше. Причем, повышенную нагрузку я наблюдал даже при операциях поиска в большом каталоге. Решил не рисковать и избавился от RAID10 в таком варианте.

Странно. Ведь все «центрально симметрично». (A-B) (B-A). Возможно это как раз из-за того, что весь диск был выдан рейду? Тогда из-за падения скорости на внутренних дорожках действительно будет почти в два раза медленней проверка и перестройка диска.

soomrack ★★★★
()
Ответ на: комментарий от YAR

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

YAR ★★★★★
()
Ответ на: комментарий от soomrack

Думаю, дорожки тут ни при чем.

Как я себе это представляю: возьмем 2 диска, раскидаем данные согласно алгоритму, получим

-> | a | | b | <-
| b | | a |
| c | | d |
| d | | c |

Первый диск при resync'e читает у нас блоки последовательно - а, b, с, d - и последовательно перемещает головы в одном направлении. Тут все ок. А вот второй - читает а, перемещается назад, читает b, потом перемещается далеко вперед, читает с, потом снова назад и читает d. И так постоянно. А итоговая скорость массива, как мы помним - скорость самого медленного диска.

YAR ★★★★★
()
Ответ на: комментарий от YAR

Стрелки не нужны / не там, ну да ладно. Еще дополню - хотя такой вариант был бы идеален, например, на SSD, где не надо двигать головами :)

YAR ★★★★★
()
Ответ на: комментарий от YAR

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

Вырезать все равно можно. Схема расположения копий известна.

Вероятность того, что появятся два беда, которые одновременно затрут все копии информации примерно одинакова и для raid10 и для raid1. Более того, если диски из одной партии, то есть подозрение, что повышенную вероятность появления бэдов имеют одинаковые участки, следовательно, raid10 с разносом копий будет немного более устойчив к таким (очень маловероятным) событиям.

soomrack ★★★★
()
Ответ на: комментарий от soomrack

В случае с зеркалом используем простой ddrescue. В случае с несимметричным RAID1 получаем много геморроя. Ну и в любом случае это как дополнительная причина - просто хотел обезопаситься еще и с этой стороны. Основная - скорость работы и нагрузка на диски. В случае чего покупать новый сейчас не сильно хочется :)

YAR ★★★★★
()
Ответ на: комментарий от YAR

Как я себе это представляю: возьмем 2 диска, раскидаем данные согласно алгоритму, получим

Это близкая запиcь -p n2.

При -p f2 — дальней записи копии данных начинают располагаться с середины диска.

Типа такого:
|a||b|
|c||.|
|.||a|
|b||c|

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

soomrack ★★★★
()
Ответ на: комментарий от YAR

В случае с зеркалом используем простой ddrescue. В случае с несимметричным RAID1 получаем много геморроя.

Ну не то чтоб очень много, но простенький скрипт написать придется.

Ну и в любом случае это как дополнительная причина - просто хотел обезопаситься еще и с этой стороны. Основная - скорость работы и нагрузка на диски. В случае чего покупать новый сейчас не сильно хочется :)

Не уверен, но при 10 рейде внутренний кеш диска должен лучше использоваться и, соотв. нагрузка должна быть меньше. Но все зависит от задач. Если для рейд нужен для системы — то тут без разницы, больше пользы принесет тюнинг фс, если для бс с классическим датамайнингом (очень большие таблицы, запросы на всю таблицу), то raid10 должен дать прирост скорости...

soomrack ★★★★
()
Ответ на: комментарий от soomrack

и дерганья головки не происходит.

Почему? а, с идут подряд. А дальше на первом диске читаем последовательно идущий ".", а на втором диске прыгаем назад.

Это близкая запиcь -p n2.

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

Но тут, имхо, важно, чтобы readahead захватывал чтение следующего блока на этом же диске.

Ну вот, readahead вроде есть, а дерганье тоже есть.

YAR ★★★★★
()
Ответ на: комментарий от YAR

Почему? а, с идут подряд. А дальше на первом диске читаем последовательно идущий ".", а на втором диске прыгаем назад.

Обычно чтение идет только с первой половины каждого диска:

диск1: aceg.bdf
диск2: bdf.aceg

Мы хотим прочитать данные «bcde»: параллельно читаются «bd» и «ce», при этом дерганья головки не происходит.


Это близкая запиcь -p n2.

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

имхо, только если файлы большие и readahead в два раза больше чем для -p f2

soomrack ★★★★
()
Ответ на: комментарий от soomrack

Мы хотим прочитать данные «bcde»: параллельно читаются «bd» и «ce», при этом дерганья головки не происходит.

Стоп. Мы уехали от темы. Я уже писал - при обычной работе все было более-менее ок, проблема была, например, при ежемесячной проверке диска - когда ядру надо читать параллельно _одинаковые_ блоки, чтобы их сравнить.

YAR ★★★★★
()
Ответ на: комментарий от YAR

Стоп. Мы уехали от темы. Я уже писал - при обычной работе все было более-менее ок, проблема была, например, при ежемесячной проверке диска - когда ядру надо читать параллельно _одинаковые_ блоки, чтобы их сравнить.

В этом случае тоже все читается параллельно:

с начала первого диска: «aceg»

с середины второго диска: «aceg»

Проверка диска ведь делается на онсове его структуры, а не на основе данных, размещенных на нем.

soomrack ★★★★
()
Ответ на: комментарий от soomrack

с начала первого диска: «aceg»
с середины второго диска: «aceg»

Правильно. А дальше? С середины первого диска «bdf.» (которые идут за aceg) параллельно с этими же блоками, которые находятся где? В начале второго диска, на которое надо спозиционироваться.

YAR ★★★★★
()
Ответ на: комментарий от YAR

Правильно. А дальше? С середины первого диска «bdf.» (которые идут за aceg) параллельно с этими же блоками, которые находятся где? В начале второго диска, на которое надо спозиционироваться.

Одно дополнительно позиционирование головки диска на проверку ВСЕГО рейда это ведь не «нагрузка на механику»?

soomrack ★★★★
()
Ответ на: комментарий от soomrack

А кто сказал, что оно одно? Или ты на полном серьезе говорил про середину физического диска? Блоки находятся удаленно друг от друга, но про середину диска речь не идет. Т.е., после показанного тобой примера идет следующий набор блоков с одной последовательностью на одном диске и другой - на другом. Позиционирование происходит как раз в пределах одной последовательности и между последовательностями. Насколько часто - надо точно знать алгоритм раскидывания блоков.

YAR ★★★★★
()
Ответ на: комментарий от YAR

А кто сказал, что оно одно? Или ты на полном серьезе говорил про середину физического диска? Блоки находятся удаленно друг от друга, но про середину диска речь не идет.

На полном серьезе. В этом вся суть -p f2.

soomrack ★★★★
()
Ответ на: комментарий от soomrack

When 'far' replicas are chosen, the multiple copies of a given chunk are laid out quite distant from each other. The first copy of all data blocks will be striped across the early part of all drives in RAID0 fashion, and then the next copy of all blocks will be striped across a later section of all drives, always ensuring that all copies of any given block are on different drives.

Где тут середина? Речь идет про большее удаление и «более поздний участок диска», но не середину.

YAR ★★★★★
()
Ответ на: комментарий от soomrack

Ок, а где про то, что показанный 2-й сектор на 2-м диске находится в середине? Диск, как там сказано, делится на f секций (например, 100500). Тебе показали только 1-ю и 2-ю секцию.

YAR ★★★★★
()
Ответ на: комментарий от YAR

Ок, а где про то, что показанный 2-й сектор на 2-м диске находится в середине? Диск, как там сказано, делится на f секций (например, 100500). Тебе показали только 1-ю и 2-ю секцию.

так ведь -p f2 означает, что f=2.

soomrack ★★★★
()
Ответ на: комментарий от ioan

Узкое место в настоящее время - это железо винта.

azure ★★
()
Ответ на: комментарий от soomrack

The number is the _number of copies_ of each datablock. 2 is normal, 3 can be useful. This number can be at most equal to the number of devices in the array.

f в мане и f в статье на Википедии - просто совпадение.

YAR ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.