md raid5 очень медленно при сбросе

md raid5 очень медленно при сбросе

Привет всем экспертам md raid

Работаю на Centos 8 (со всеми последними обновлениями, ядро ​​4.18.0-240.1.1.el8_3.x86_64), где у меня есть 3x2T Samsung SSD 860 QVO 2TB в raid5 (будет использоваться в качестве базы для некоторых виртуальных машин KVM), и когда я делаю что-то, что включает в себя отбрасывание, это не просто медленно, это намного сложнее, чем можно использовать. Я создал 1,5T LV и затем сделал "mkfs.ext4", который, через 4 часа этап отбрасывания сказал мне "Отбрасывание блоков устройства: 10489856/409148416", и сначала я подумал "4 часа на 25%, это отстой", но потом я понял, что это всего 2,5%, так что мы говорим о неделе!

Я разбил рейд и выполнил blkdiscard на трех отдельных дисках, на каждый ушло около 18 секунд.

Оборудование представляет собой HP Proliant DL380p Gen8 с контроллером Smart Array P420i (никаких специальных драйверов, все с использованием стандартных драйверов Centos), который я настроил для режима HBA, поэтому он должен быть просто транзитным (отбрасывание вообще не поддерживается при использовании аппаратного RAID).

После сброса данных на устройствах я снова создал рейд с помощью

mdadm --create /dev/md20 --level=5 --raid-devices=3 --chunk=64 /dev/sd{b,d,e}1

Я оставил его на ночь для синхронизации. Затем я создал vg и протестировал создание lv, потребовалось 7 минут, чтобы сбросить 100M

root@terrok:~ # lvcreate -nDELME -L100M vgssd2  && date && time mkfs.ext4 /dev/vgssd2/DELME && date && time lvremove -f /dev/vgssd2/DELME;date
  Logical volume "DELME" created.
Mon Dec 21 12:47:42 EST 2020
mke2fs 1.45.6 (20-Mar-2020)
Discarding device blocks: done
Creating filesystem with 102400 1k blocks and 25688 inodes
Filesystem UUID: f7cf3bb6-2764-4eea-9381-c774312f463b
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729

Allocating group tables: done
Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done


real    7m20.095s
user    0m0.004s
sys     0m0.195s
Mon Dec 21 12:55:02 EST 2020
  Logical volume "DELME" successfully removed

real    7m17.881s
user    0m0.018s
sys     0m0.120s
Mon Dec 21 13:02:20 EST 2020
root@terrok:~ #

Для сравнения, в той же системе у меня также есть два WDC WDS100T2B0A-00SM50 (1T SSD) в raid1, и там сброс работает намного быстрее, 4 секунды для 10G.

Затем я взял два SSD-накопителя Samsung и сделал из них raid1, полная скорость на сбросе. Повторил для двух других комбинаций дисков и никаких проблем. Для меня это указывает на какую-то проблему с raid5. Сейчас у меня два SSD-накопителя в raid1 с одним горячим резервом, и это, по крайней мере, работает, но, конечно, на 2T меньше места, чем я рассчитывал.

Есть ли какие-нибудь предложения, что можно сделать, чтобы это можно было использовать с raid5?

решение1

Как показали ваши тесты, RAID5 действительно требует более интенсивных операций, чем простой массив RAID 1. Потому что RAID 1 — это буквально просто синхронизация между двумя дисками, вот и все.

С другой стороны, RAID 5 должен выполнять все эти вычисления между тремя дисками.ивыравниваем их по четности. Это большая работа, по крайней мере по сравнению с «простым» массивом RAID 1.

Также в качестве побочного штриха, диски QVO не идеальны для таких нагрузок, как обслуживание виртуальных машин, которые обычно требуют больших затрат на деятельность дисков. Также не подходят массивы четности, такие как RAID 5 и т. д. Вы можете пересмотреть свои стратегии развертывания с учетом сказанного и ситуации с самим RAID5.

решение2

Я только что тоже занялся этой проблемой. Я покопался в драйвере raid5 и обнаружил, что raid5 разбивает входящий запрос на сброс на запросы сброса по 4k на базовых устройствах. Более того, он был сломан довольно давно, так что он фактически игнорирует devices_handle_discard_safely. В результате все сбросы по 4k выполняются синхронно с базовым устройством, что делает эту операцию еще более медленной в целом. Примечание: я скоро перенесу это в LKML, так что вы можете следить за обновлениями там. Я не знаком ни с одним обходным путем, доступным для существующих ядер.

Связанный контент