software raid тормозит

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

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

Это чтение?

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

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

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

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

dd if=/dev/zero

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

попробовал с bs=10M, 82мб/с. всё равно не дотягивает до 130-140мб/с :(

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

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

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

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

записи
round-robin

Это типа шутка?

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

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

Нет так давно в закладки добавил: http://habrahabr.ru/blogs/linux/111036/
Правда, там про RAID-6...

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

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

скорость чтения файла через 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

nobarrier

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

:)

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

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

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

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

sync; sync; sync
sysctl vm.drop_caches=3

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

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

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

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

Видимо, мне тогда везло больше: dmraid isw, пропадает файл устройства раздела (комментарий)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

http://en.wikipedia.org/wiki/Non-standard_RAID_levels

«The driver also supports a „far“ layout where all the drives are divided into f sections. All the chunks are repeated in each section but offset by one device. For example, f2 layouts on 2-, 3-, and 4-drive arrays would look like:»

то что я выше рисовал.

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

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

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

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

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 в статье на Википедии - просто совпадение.