Медленная повторная синхронизация 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, который выявил тысячи сломанных секторов. Замена этого диска новым исправила проблему для меня.

Другие вопросы по тегам