Чем можно заняться в 0 часов 0 минут в Москве? Сидеть за праздничным столом и праздновать? Как бы то ни было.
В этот праздничный момент я хочу поделиться с вами моим текущим исследованием по настройке производительности soft trade на домашнем сервере.
Можно пропустить теорию и сразу прочитать последний абзац, где и есть основная соль.
Почему RAID-6?
Как известно, RAID-5 выдерживает гибель одного веника, а после этой самой смерти - пока не будет завершено восстановление рейда с новым жестким диском - ваши данные подвергаются риску - восстановление обычно занимало до 70 часов для больших массивы и еще одна метла в это время запросто могут сдохнуть.
RAID-6 выдерживает гибель любых 2-х веников.
Из минусов общепринятое мнение, что он тормозит, особенно запись, даже по сравнению с RAID-5. Что ж, давайте проверим это.
Почему софттрейд?
Железный рейд нужен только в одном случае - если у него есть аккумулятор и встроенный кэш.Тогда контроллер сразу отвечает ОС, что запись на диск завершена на физическом уровне и всякие ACID базы работают очень быстро и безопасно.
В остальных случаях никаких бонусов по сравнению с мягким рейдом нет, только недостатки: 1) Утюг сгорел? Новый сервер? Пожалуйста, купите тот же контроллер или молитесь за совместимость.
Софттрейд из одних и тех же дисков собирается где угодно.
2) Цена:-) Собственно из-за этого я ни разу не проводил нормальных рейдов с аккумулятором в руках:-) Ну а те «рейд-контроллеры», которые встречаются на обычных материнских платах, использовать вообще нельзя.
Они просто позволяют загружать ОС из рейда с помощью встроенного биоса (который выполняет центральный процессор, собственного процессора нет), на этом их преимущества заканчиваются, и остаются только недостатки.
О паре мифов о софттрейде
1) Он съедает много драгоценного процессора Если мы бегло взглянем на исходный код драйвера RAID в ядре Linux, то увидим, что там всё уже давно оптимизировано под SSE2. А с SSE2 процессор может читать XOR из 16 байт за 1 такт на 1 ядре современного процессора, и все зависит от скорости обмена с памятью.Можете прикинуть какой процент нагрузки на одно ядро будет генерировать поток 1Гб/сек :-) А ядер много :-) На практике с моим Opteron 165 (1.8Ghz 2 ядра) скорость ни разу не ограничивалась процессором.
2) Он развалится, а потом вы соберете его обратно.
Если что-то и отваливается, то это из-за железа (например, обычные винты иногда любят делать всякие фоновые задачи).
Добавление упавшей метлы – простая операция, которая также может выполняться автоматически.
Однако в среднем это следует делать один раз в год. mdadm /dev/md0 -a /dev/sde1 3) У Softtrade дерьмовый мониторинг Все отлично и настраивается с мониторингом.
Например, достаточно просто указать мыло в конфиге mdadm и оно отправит вам письмо, если что-то случится с вашим массивом.
Очень удобно) Например, вот что произойдет, если одна метла упадет:
Это автоматически созданное почтовое сообщение от mdadm, работающего на XXXXX.Рекомендую протестировать перед использованием: mdadm --monitor -1 -m [email protected] /dev/md0 -t 4) У Softtrade очень низкая скорость реструктуризации массива В конфигурации по умолчанию - да.
Событие DegradedArray было обнаружено на устройстве md /dev/md0.
С уважением и т. д.
P.S. В настоящее время файл /proc/mdstat содержит следующее:
Личности: [raid6] [raid5] [raid4]
md0: активный рейд6 sda1[1] sdc1[4] sdd1[3] sde1[2]
2929683456 блоков super 1.2 уровня 6, чанк 1024 тыс.
, алгоритм 2 [5/4] [_UUUU] неиспользуемые устройства: нет
А если вы дочитаете статью до конца, то узнаете, как сделать так, чтобы все перестраивалось со скоростью самой медленной метлы :-)
О роли растрового изображения
Программное обеспечение Linux поддерживает замечательную функцию: растровое изображение.Там отмечаются измененные блоки на диске, и если по каким-то причинам один диск из массива отвалился, а потом вы добавили его обратно, полная пересборка массива не требуется.
Чертовски полезно.
Хранить его можно на самом рейде - внутреннем, или в отдельном файле - но есть ограничения (по типу файловой системы, например).
Я сделал внутреннее растровое изображение.
И зря.
Внутреннее растровое изображение невероятно медленное, потому что.
Головка метлы постоянно дергается при записи.
Посмотрим на скорость:
Скорость можно проверить например так:time sh -c «dd if=/dev/zero of=ddfile bs=1M count=5000» time sh -c «dd if=ddfile of=/dev/null bs=1M count=5000»Результаты для моего RAID-6 от 5xWD 1TB были следующими: чтение 268МБ/сек, запись 37МБ/сек.
Все пожимают плечами и говорят: ну что ты хотел? RAID-6 тормозит при записи, поскольку ему необходимо прочитать то, что было записано ранее, чтобы вычислить обновленные контрольные суммы для всех дисков.
А еще это растровое изображение.
Скорость реконструкции массива около 25 МБ/сек, полная реконструкция массива занимает до 15 часов.
Это твой кошмар.
Проблемы решаются просто:
- Драйвер рейда Linux имеет этот полезный параметр:stripe_cache_size.
значение по умолчанию которого 256. Слишком низкое значение - резко снижает скорость записи (как оказалось).
Оптимальное значение для многих — 8192. Это количество блоков памяти на 1 диск.
1 блок обычно 4кб (в зависимости от платформы), для 5-дискового массива кэш займет 8192*4кб*5 = 160Мб.
эхо 8192 > /sys/block/md0/md/stripe_cache_size Он начинает работать мгновенно.
Теперь в большинстве случаев драйверу не приходится читать диск перед записью (особенно при линейной записи), и производительность резко возрастает. После перезагрузки он пропадает, чтобы не пропадал добавьте его в какой-нибудь /etc/rc.local например.
Скорость восстановления массива теперь 66МБ/сек (это для всех дисков сразу, около 5 часов на весь массив), скорость чтения осталась прежней, но скорость записи выросла до 130МБ/сек (с 37).
- Переносим растровое изображение на отдельный диск (в моем случае системный).
Если системная метла сдохнет, ничего страшного, массив восстановится без битмапа.
Голова больше не дергается при очередной записи, а скорость записи увеличивается до 165 МБ/сек.
mdadm -G /dev/md0 -b /var/md0_intent
165 МБ/сек.
(более 4 раз!!).
Теперь через Samba по сети файлы пишутся и читаются со скоростью 95-100 МБ/сек, а запланированный апгрейд сервера из-за низкой скорости рейда придется отложить на неопределенный срок - производительность дохлого Opteron 165 сейчас на уровне более чем достаточно для всех задач :-)
С Новым Годом :-) ПС.
Внимание! Ходить под корень только трезвым! ПС.
В нелегком бою первый пост на Хабре в 2011 году был опубликован мной.
ПС.
инфа
Теги: #linux #настройка Linux #производительность #raid6 #raid5 #raid5
-
Вы Видели Млечный Путь?
19 Dec, 24 -
Хедж-Фонды Доигрались?
19 Dec, 24
