LINUX.ORG.RU
ФорумAdmin

Тормозит raid6, не могу найти причину

 , , ,


0

4

Собрал я намедни файлопомоечку, поставил систему, сделал raidz2, начал заполнять и удивился тормозам. Копирование на массив по сети со скоростью в районе 400МБ/с вызывало load average 26. Аналогичная картина случилась и в связке mdadm+luks, повторилась на других ядрах и дистрибутивах. Когда похожая ситуация случилась после переноса части массива (диски + HBA) на другое железо, было принято решение менять HBA.

Китайский 9205-8i был заменён на родной (по заверениям продавца) H310, load average спустился на землю, но проблема со скоростью осталась - что zfs raidz2, что mdadm raid6 отказываются работать быстрее 600МБ/с на одном массиве. При этом все винты по отдельности одновременно под аналогичной нагрузкой показывают нормальную скорость. Тесты упростились до dd if=/dev/zero…, если запустить 18 на все диски одновременно - каждый винт выдаст максимально возможную скорость, если собрать raid6 - аналогичное dd выдаст в лучшем случае 600МБ/с, при этом нагрузка равномерно разделится по дискам и ни на одном из них не будет 100% использования. Если собрать 3 массива из 6 дисков в каждом - будет 600х3.

Тестировалось: proxmox 6 с ядрами 5.3.18-3-pve и 5.4.34-1-pve, дебиан 10 с 4.19 и собранным из исходников 5.3.18, какая-то 16 убунта с её родным ядром. Везде ситуация одинаковая. Да, биос последний, mitigations=off, разницы не заметил.

Железо: 2x E5-2620, 96GB DDR3, X9DRI-F, CSE846 с BPN-SAS2-846EL1, H310 (9211-8i), 18 штук WD80EMAZ.

Единственное, что приходит в голову - тормознутые процессоры, но не может же не самый тормозной xeon времён sandy bridge работать медленнее amd a4-3400?

Удалить всё из /var/cache кроме папки apt если такая есть , отключить все диски и очистить /media , выполнить sudo rm -rf ~/.local/share/gvfs-metadata/* && sudo rm -rf root/.local/share/gvfs-metadata/*

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

так объедени их в raid0

И потерять 4 диска на чётность?

а сколько ты хочешь?

Хотя бы 1.2ГБ/с, чтобы иметь возможность забить 10 гигабит. Но вообще, соседняя файлопомойка с 14-дисковым raid6 средствами mdadm и luks поверх выдаёт 1.8ГБ/с, хочется получить как минимум столько же.

koi-sama ()

Если собрать 3 массива из 6 дисков в каждом - будет 600х3.

Если аппаратный рейд собрать(у тебя ж там LSI, там же есть аппаратный RAID?) - скорость выдаётся как надо?

Какой планировщик I/O используется? mq-deadline?

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

У меня HBA. Можно конечно поиграться и перешить в IR, но изначально хотелось вообще zfs. Если с точки зрения скорости до дисков - там всё ок, параллельные dd или badblocks показывают в начале дисков убедительные 3.4ГБ/с в сумме.

Планировщик - да, mq-deadline, в proxmox остался только он и noop.

edit: %util на дисках в момент копирования где-то в районе 60, с кривым планировщиком было бы 100 и рос бы iowait?

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

но изначально хотелось вообще zfs

Так никто не против. Пусть будет zfs на каком нибудь /dev/sda. Который в свою очередь уже - аппаратный RAID-6 или RAID-100500.

Мой не так чтобы большой опыт подсказывает, что, несмотря на то что софтверный рейд в линуксе - это вполне себе годнота на дрыщесерверах, но при наличии нормального(не встроенного в мать какого-нибудь intel raid-а...) контроллера - лучше контроллер. При условии конечно что у тебя есть запасной такой, ну или нормальные бэкапы(которые в любом случае не повредят).

Pinkbyte ★★★★★ ()
Ответ на: комментарий от koi-sama

Необходимо добавить oflag=direct в эту команду. Чтобы запись на диски не шла сначала в dirty кеш. Если будешь тестить чтение, то добавь iflag=direct. Без этих параметров получается такой себе тест оперативки.

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

Да, думал echo 3 > /proc/sys/vm/drop_caches достатчоно.

С чтением и iflag=direct получилось 1.8ГБ/с, что уже заметно ближе к правде. С записью и oflag=direct скорость упала до 250МБ/с. stripe_cache_size выставлен 6144, практика другого массива показывает что этого достаточно чтобы диски при последовательной записи не дёргались. Всё равно фигня какая-то.

koi-sama ()
Ответ на: комментарий от Pinkbyte

zpool create -O keyformat=passphrase -O keylocation=prompt -O mountpoint=/mnt/zraidz2 -O dnodesize=auto -O normalization=formD -O relatime=on -O xattr=sa -o ashift=12 -O encryption=aes-256-gcm zraidz2 raidz2 /dev/disk/by-id/ata-WDC_WD80EMAZ-00WJTA0_????????

Шифрование в дальнейших тестах было выключено.

Нормальный контроллер - это целая куча геморроев: его купить надо сперва, запасной держать, массивы на них весьма хрупкие по сравнению с мдадмом, по крайней мере аппаратные рейды, пусть и в тестовых целях, я убивал, а мдадмовый в реальности не умирал ни разу. На имеющихся у меня entry-level HBA с рейдовым функционалом, без батареек и памяти, я бы серьёзный массив делать не стал.

koi-sama ()
Ответ на: комментарий от koi-sama

entry-level HBA с рейдовым функционалом, без батареек и памяти, я бы серьёзный массив делать не стал.

Ааа, окей, не посмотрел на модель. Тогда вопросов не имею.

Pinkbyte ★★★★★ ()
Ответ на: комментарий от koi-sama

drop_caches достаточно, при тестах на чтение, если есть полная уверенность, что дисковый и/или файловый кеш точно не при чём. На запись (без oflag=direct) данные в любом случае сначала попадают в dirty кеш и потом уже на диск. Поэтому показатели скорости получаются неправильными.

По поводу 250 мб/с. Есть вариант попробовать писать блоком равным (stripe size * количество дисков с данными в масиве). Чтобы один блок записи гарантинованно разделялся между всеми дисками с данными («диски» чётности не считаем).

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

chunk_size=128k, блоками по 2М - 100% загрузка дисков, 0 чтения и 580МБ/с, блоками по 36М - 35% загрузка дисков и 700МБ/с. iowait не растёт, md6_raid6 в этот момент жрёт 75% от одного ядра.

В принципе, можно было бы на этом моменте и остановиться и списать проблемы на методику тестирования. Но блин, рядом стоит машина с mdadm+luks, которая на меньшем количестве дисков показывает намного более впечатляющий результат.

koi-sama ()

если запустить 18 на все диски одновременно - каждый винт выдаст максимально возможную скорость, если собрать raid6 - аналогичное dd выдаст в лучшем случае 600МБ/с, при этом нагрузка равномерно разделится по дискам и ни на одном из них не будет 100% использования. Если собрать 3 массива из 6 дисков в каждом - будет 600х3.

А на рейд ты тоже 18 копий dd запускаешь или одну?

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

Она и стоит. На 9205 я перед тем как принять решение о замене HBA ставил P19. Да и в любом случае, я их как HBA использую.

Я про IT-firmware (HBA). В предыдущих диски либо не все определялись, либо отстреливались от системы в работе (соответственно, zfs их, разумеется, отстреливала из массива и херилась, т.к. raidz2 не переживал потерю 4х дисков из 8)

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

Двумя. С одним кабелем такая же ерунда, впрочем, только что максимальная одновременная скорость до дисков проседает в 2 раза. Один из линков с парой кабелей не поднимается на 9211, но это мелочи.

# smp_discover /dev/bsg/expander-1\:0
  phy   0:S:attached:[5c81f660e137cb00:03  i(SSP+STP+SMP)]  6 Gbps
  phy   1:S:attached:[5c81f660e137cb00:02  i(SSP+STP+SMP)]  6 Gbps
  phy   2:S:attached:[5c81f660e137cb00:01  i(SSP+STP+SMP)]  6 Gbps
  phy   4:U:attached:[5c81f660e137cb00:07  i(SSP+STP+SMP)]  6 Gbps
  phy   5:U:attached:[5c81f660e137cb00:06  i(SSP+STP+SMP)]  6 Gbps
  phy   6:U:attached:[5c81f660e137cb00:05  i(SSP+STP+SMP)]  6 Gbps
  phy   7:U:attached:[5c81f660e137cb00:04  i(SSP+STP+SMP)]  6 Gbps
koi-sama ()
Ответ на: комментарий от koi-sama

Я с экспандерами дела стараюсь не иметь (и не имел пока, слава аллахам, больно уж они капризные), но вроде как для EL1 надо подключать одним кабелем, или я не прав?

Также встречал ранее информацию, что связка «контроллер+экспандер+диски» гораздо более капризная с т.з. HCL, чем просто «контроллер+диски» и надо смотреть HCL: http://web.archive.org/web/20180324201022/http://www.supermicro.com/products/...

Один из линков с парой кабелей не поднимается на 9211

Не понял?

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

Я бы тоже предпочёл тупой бэкплейн, но что есть. 2 порта поддерживаются далеко не везде, но в целом экспандерам обычно наплевать и оно работает. SAS - довольно гибкая штука.

Не понял?

В одном 8087 4 канала, т.е. с логической точки зрения HBA к экспандеру подключается 4 или 8 каналами в зависимости от того сколько физических коннекторов подключено. Когда стоял глючный 9205, поднималось 8 линков, с 9211 - только 7. Что в принципе неплохо, потому что люди жаловались на то, что связка 9211 и экспандера выдаёт скорость в 2 раза меньше положенной.

koi-sama ()
Ответ на: комментарий от koi-sama

А смысл? Файловая система в случае с mdadm в тестах вообще не участвует.

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

anonymous ()

Пошаманил я ещё немного с бубном, попробовал другое железо - десктопный i3-4130, попробовал разные комбинации портов на HBA и экспандере - всё без толку. С другим железом сетевого копирования не вышло - там один pcie x16 всего, но забитие нулями с mdadm оказалось столь же тормознутым. Попробовал ещё более древнюю 14 убунту с не менее древним mpt3sas, принципиально ничего не изменилось.

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

koi-sama ()
Ответ на: комментарий от koi-sama

с 9211 - только 7

Мне кажется, дело в этом. Ну не конкретно в 7 линках вместо 8, а в несовместимостями какого-то оборудования или дефектного контроллера.

Другими словами, сначала надо физику исправлять, а потом уже zfs/mdadm тюнить. ИМХО.

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

Так контроллер менялся - c 9205 при копировании был безумный load average. Можно предположить, что sas2 контроллер с чипом от lsi плохо дружит с sas2 экспандером с чипом от lsi, но это звучит крайне странно. Может, конечно, у 9211 (и любого другого контроллера с 2008 на борту) есть проблемы совместимости с экспандерами, но именно такое проявление этих проблем выглядит крайне странным.

У меня пока 2 идеи - поскольку тестирование на других железках было весьма поверхностным, можно продолжить допиливание сервера и как и планировалось, купить нормальные процессоры - пару E5-2650v2. Если ZFS с ними выйдет на 700-800МБ/с записи (а она очевидно упирается в процы, потому что нагрузка с zfs при записи взлетает до 16-17) - можно так и оставить. Второй вариант - дальше менять контроллеры, найти заведомо исправный 9207 или что-то на sas3008, но это дополнительные траты денег на железо, которое мне кроме как для тестов и не нужно.

Можно было бы без экспандера попробовать, но тупой бэкплейн стоит 100 баксов, которые и так есть куда потратить.

koi-sama ()