Медленная повторная синхронизация raid5 с накопителями WD Green
Вопрос
Почему моя первоначальная повторная синхронизация происходит так медленно? Первоначально cat /proc/mdstat сообщается ~ 30000K/sec,
- Я тогда увеличил
/sys/block/md0/md/stripe_cache_sizeот256в16384, Это увеличило скорость до~50000K/sec, - Я изменился
/proc/sys/dev/raid/speed_limit_minот1000в100000а также/proc/sys/dev/raid/speed_limit_maxот200000в400000, но это не помогло.
Что еще я могу сделать, чтобы ускорить процесс?
- В этой теме предлагается заменить диски Western Digital Green чем-то другим. Это не вариант для меня.
- Бег
smartctl -t short /dev/sd[bcd]и позжеsmartctl -l selftest /dev/sd[bcd]не выявил никаких ошибок. - Ряд ресурсов, которые я нашел по теме ( 1, 2), не очень конкретен о том, как (какие команды) изменять определенные настройки, и не очень хорошо объясняет, что они делают и почему они помогают.
Некоторый Фон
Как я настраиваю рейдовый массив
Я только что добавил три накопителя Western Digital SATA емкостью 2 ТБ (их "зеленая" серия) на свой сервер Ubuntu 14.04. Они есть /dev/sd[bcd],
Я решил использовать их в массиве raid5 и настроить все так:
1) Создайте один раздел на каждом диске: fdisk /dev/sdb (то же самое для sdc а также sdd)
Основываясь на этом сообщении в блоге, я выбрал 2048 а также 3907029128 как соответствующий первый и последний сектор на каждом диске. Эти числа делятся на 4, так как эти диски являются дисками сектора 4K.
Тип fs был установлен на da (Non-FS data) согласно этому сообщению в блоге, в котором говорится
Это останавливает распространение сценариев авто-монтирования для поиска суперблоков на дисках, помеченных как "fd", и попытки монтировать их в забавном порядке.
Поскольку массив raid не является обязательным для загрузки системы, это имеет смысл для меня.
2) создать массив raid используя mdadm : mdadm --create --verbose /dev/md0 --level=5 --chunk=2048 --raid-devices=3 /dev/sdb1 /dev/sdc1 /dev/sdd1 --spare-devices=0 --force
--chunk=2048 Опция была также вдохновлена тем же сообщением в блоге: "Помните, что логика" должна делиться на 4 ".
--spare-devices=0 --force варианты - мое собственное творение, так как без них mdadm команда запустит начальный процесс повторной синхронизации, но быстро замедлится до < 200K/sec, а затем выручить с сообщением в /var/mail/root тот /dev/sdd "возможно, не удалось". После этого, выход mdadm --detail /dev/md0 показал бы, что /dev/sdd1 был перемещен, чтобы быть запасным двигателем.
После добавления этих параметров повторная синхронизация продолжается. Сначала он замедлился до < 100K/sec но затем скорость увеличилась примерно до 30000K/sec и остался там.
О запущенном процессе повторной синхронизации
atop показывает, что /dev/sdd самый медленный
DSK | sdd | busy 103% | read 930 | write 304 | KiB/r 512 | | KiB/w 512 | MBr/s 46.50 | MBw/s 15.20 | avq 112.12 | avio 8.10 ms |
DSK | sdc | busy 85% | read 942 | write 384 | KiB/r 508 | | KiB/w 410 | MBr/s 46.75 | MBw/s 15.40 | avq 20.59 | avio 6.21 ms |
DSK | sdb | busy 73% | read 942 | write 387 | KiB/r 508 | | KiB/w 411 | MBr/s 46.75 | MBw/s 15.55 | avq 17.31 | avio 5.31 ms |
О дисках WD Green
Все диски были куплены в разное время (поэтому я подозреваю, что они из разных серий, с интервалом в несколько месяцев). /dev/sdb а также /dev/sdc являются самыми молодыми и имеют кэш 64 МБ. /dev/sdd имеет кэш 32 МБ.
1 ответ
Спустя всего несколько минут после публикации этого вопроса первоначальная повторная синхронизация снова отменилась, переместив самые старые из моих дисков в "свободное" место, прежде чем даже достигнуть 100%.
Хотя устройство не выявило smartclt проблем, оказалось, что это было на самом деле сломано. Это было установлено badblocks, который выявил тысячи сломанных секторов. Замена этого диска новым исправила проблему для меня.