LINUX.ORG.RU
ФорумAdmin

mdadm raid 10, низкая скорость записи

 , , , ,


1

6

Забросил в десяточку 4 ssd, но был неприятно удивлен тем, что скорость записи по сравнению с 0 из таких же двух дисков меньше примерно на 100 МБ/с.

Можно ли это как то потюнить?

root@heaven:~# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.2
  Creation Time : Tue Jan 21 22:51:20 2014
     Raid Level : raid10
     Array Size : 234306560 (223.45 GiB 239.93 GB)
  Used Dev Size : 117153280 (111.73 GiB 119.96 GB)
   Raid Devices : 4
  Total Devices : 4
    Persistence : Superblock is persistent

    Update Time : Wed Jan 22 00:04:35 2014
          State : clean 
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0

         Layout : near=2
     Chunk Size : 512K

           Name : heaven:0  (local to host heaven)
           UUID : 5155f4fc:50b2514c:98a29b0b:4644b1d6
         Events : 26

    Number   Major   Minor   RaidDevice State
       0       8        1        0      active sync   /dev/sda1
       1       8       17        1      active sync   /dev/sdb1
       2       8       33        2      active sync   /dev/sdc1
       3       8       49        3      active sync   /dev/sdd1
В 0 такая же мулька дает 360 МБ/с, в десяточке - минус 100
root@haven:~# time dd if=/dev/zero of=/tmp/1 bs=1M count=256 conv=fdatasync
256+0 records in
256+0 records out
268435456 bytes (268 MB) copied, 1.04119 s, 258 MB/s

real	0m1.048s
user	0m0.000s
sys	0m0.328s
Красиво, но далеко от реальности:
root@haven:~# hdparm -Tt /dev/md0

/dev/md0:
 Timing cached reads:   13452 MB in  2.00 seconds = 6733.00 MB/sec
 Timing buffered disk reads: 1884 MB in  3.00 seconds = 627.28 MB/sec
Пользуясь случаем, кастану true_admin

★★★★

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

Layout : near=2

Пользуясь случаем, спрошу. Есть ли в интернетах вменяемое описание, что означают «near» и «far», в контексте mdadm raid10. В идеале - с картинками

router ★★★★★
()

1) В дебияне есть косяки со скоростью дисков

2) Не наворотил ли ты битмапов в рейде?

3) Чего слышно про выравнивание данных на ssd?

anonymous
()
Ответ на: комментарий от router

Нашёл:

http://www.ilsistemista.net/index.php/linux-a-unix/35-linux-software-raid-10-...

число 2 - это просто 2 копии в raid1. А блоки в любом случае разбиваются по разным дискам. Т.е. моё невысказанное предположение, что raid0 работал как JBOD неверно, затык в скорости где-то в другом месте.

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

1) Какой именно затык? Оно есть в баглистах?

2) Не, дефолтный же. Зато скорость чтения выше чем у 0, веселуха. Вот еще рекомендуют потюнить

/sys/block/mdX/md/stripe_cache_size
- коего у меня отродясь не было.

3) TRIM, если поддерживается контроллером ну и фс само собой.

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

Да обидно блин, хотя и приятно что чтение быстрее чем в 0. Но мне запись важнее. На счет описаловки, как банально не звучит но на вики есть неплохое инфо тут

invokercd ★★★★
() автор топика
Последнее исправление: invokercd (всего исправлений: 1)
Ответ на: комментарий от invokercd

Да обидно блин, хотя и приятно что чтение быстрее чем в 0. Но мне запись важнее

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

Как правило, скорость чтения ( и особенно - IOPS на чтение ) гораздо важнее, т.к. чтение - более «дорогая» операция, чем запись. Т.к. если приложение хочет читать данные, ядро должно предоставить их относительно быстро ( десятки.. сотни миллисекунд ). А если приложение пишет данные, то никто не мешает положить их в файловый кэш и записать на диск хоть через 5 минут.

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

3) TRIM, если поддерживается контроллером ну и фс само собой.

ИМХО, анонимус имел в виду смещение msdos ( uefi? ) разделов от начала диска

fdisk -l -u -c /dev/sda
gdisk -l /dev/sda
router ★★★★★
()
Ответ на: комментарий от router

Не много, но постоянно. Ну и вообще, честно, мне обидно и я хочу хотя бы до 0 повысить скорость.

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

Я не понял про что он точно, но в тренде волнения по поводу равномерности износа накопителя.

invokercd ★★★★
() автор топика

1. Писать приходится вдвое больше на raid-10, чем на raid-0, а у тебя нет железного контроллера, который бы взял это на себя.

2. Читать можно с 4-х дисков на raid-10, поэтому скорость чтения может быть больше чем на raid-0.

sdio ★★★★★
()

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

А система при тестах была таже самая? ОС/железо не менялись?

black_13
()
Ответ на: комментарий от invokercd

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

2)Внимательнее читай нагугленное про оптимизацию рейда.

3)Не трим, а выравнивание разделов на диске.

anonymous
()

Увы, я не знаю, уже очень давно я админю только виртуалки :). А можешь показать top во время записи?

Ну и cast tazhate

true_admin ★★★★★
()

И да, попробуй писать хотя бы пару гигабайт данных. Лучше эдак гигов 10. А то тесты по секунде времени нерепрезентативны. Возможно, результат изменится.

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

1. Писать приходится вдвое больше на raid-10, чем на raid-0, а у тебя нет железного контроллера, который бы взял это на себя.

4.2. По замерам парней в яндексе mdadm быстрее железок работает и поэтому там в основном именно он.

tazhate ★★★★★
()

root@haven:~# time dd if=/dev/zero of=/tmp/1 bs=1M count=256 conv=fdatasync

1) ачотакмало? если уж использовать dd (что не хорошо и далеко от реальности), то писать надо больше, чем размер озу в системе (включая своп).
2) пиши не нули, а гоняй dbench и bonnie.

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

И да, попробуй писать хотя бы пару гигабайт данных. Лучше эдак гигов 10. А то тесты по секунде времени нерепрезентативны. Возможно, результат изменится.

Лучше писать больше в два раза, чем размер оперативы. и не использовать для тестов dd ;)

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

4.2. По замерам парней в яндексе mdadm быстрее железок работает и поэтому там в основном именно он.

А можно ссылку? По идее, всё очень сильно зависит от количества дисков, контроллеров и на каких шинах это всё висит.

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

А можно ссылку? По идее, всё очень сильно зависит от количества дисков, контроллеров и на каких шинах это всё висит.

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

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

+1. При большом кол-ве дисков (скажем, 10) я видел существенное отставание mdadm.

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

А ты уху не ел так раскидываться 4.2?

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

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

Лучше писать больше в два раза, чем размер оперативы. и не использовать для тестов dd ;)

vm.dropcaches=3 и fdatasync решают вопрос с оперативой.

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

conv=fdatasync

Лучше писать больше в два раза, чем размер оперативы. и не использовать для тестов dd

conv=fdatasync не о чем не говорит?

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

conv=fdatasync не о чем не говорит?

Да отстань ты! Проглядел.

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

С чего это 1 быстрее для чтения чем 0?

Да всё то же, разве что десятку делал в установщике, а 1 и 0 в cli с уже установленной системы.

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

машадб и кеши (мелочь типа имейджев я не считаю, это не часто и мало).

А может, zfs стоит попробовать? ^_^

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

Есть такое, но там дофига ядер и никакого (существенного) лоада при записи. Железки к сожалению там нету.

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

Ну так я хочу же. Памяти хватает, но чёто не протесчено еще оно во времени. Ты кроме теста её где то юзал (не на воркстейшн)?

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

Ну так я хочу же. Памяти хватает, но чёто не протесчено еще оно во времени. Ты кроме теста её где то юзал (не на воркстейшн)?

Да, у меня на ней файлохранилки бегают и бекапилки.

tazhate ★★★★★
()

Система ещё не в продакшене?

Загрузись с LiveCD CentOS, примонтируй тот же массив, проверь скорость. Если будет та же самая - пересоздай из-под LiveCD и опять протестируй.

Если поможет первое - проблемы в Debian-овском mdadm.

Если первое даст тот же результат, а второе поможет - то Debian-овский mdadm создаёт массивы с какими-то неоптимальными опциями.

Если не поможет не то, ни другое - ты упёрся в шину, на 4 диска надо писать в два раза больше данных.

selivan ★★★
()
Последнее исправление: selivan (всего исправлений: 1)
Ответ на: комментарий от selivan

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

Хотя опции-то в порядке.

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

Потести плиз, если это баг - он очень нехороший, надо отрепортить.

ОК, не в шину, а в контроллер SATA. Хз как оно устроено, но если шина SATA2 даёт 300 MB/s, это ещё ни разу не значт, что контроллер с 4xSATA2 даст эти 300 на каждый подключенный диск.

Допустим, контроллер с четыремя каналами максимум может пропустить через себя 400 MB/s, тогда запись на RAID0 будет 400 MB/s, а на RAID10 - 200 MB/s.

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

Постараюсь затестить.

У меня на этой же десятке было выжато ~560 МБ/с на чтение 2048K блоков.

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

Ну раз такая пляска - я соберу парочку рейдов да прогоню по скорости. Цементос не люблю, но ради такого дела. Самому стало интересно. Но там ядро то 2.6*...то бишь буду сравнивать с олдстейбл.

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