Один диск получил доступ больше, чем другие во время перестройки md RAID6
Я перестраиваю один диск из 8-дискового RAID6 (используя программный RAID-массив 'md') и заметил, что он работает не так быстро, как мог бы, предположительно потому, что один из дисков отправляется в два раза быстрее много IOPS как другие:
Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn
sda 155.00 77252.00 0.00 77252 0
sdb 153.00 76736.00 0.00 76736 0
sdc 154.00 77248.00 0.00 77248 0
sde 154.00 77248.00 0.00 77248 0
sdf 164.00 77288.00 0.00 77288 0
sdd 154.00 77248.00 0.00 77248 0
sdg 287.00 83160.00 0.00 83160 0
sdh 146.00 0.00 74240.00 0 74240
(SDH перестраивается, и SDG получает больше операций ввода-вывода в секунду, чем я ожидал).
(Я использовал mdadm /dev/md1 --add /dev/sdh4, чтобы добавить диск для замены, отказав / удалив существующий).
Вещи, которые (я думаю) я устранил:
Все диски имеют одинаковое расположение разделов (скопировано с помощью sgdisk).
sda-sdg - это идентичные диски с одинаковым номером модели (sdh является новым).
Я посмотрел на readahead, размер блока, multicount на всех дисках и не могу обнаружить никакой разницы, что sdp мог бы по сравнению с другими.
Другая перестройка на той же машине имела ту же проблему (больше обращалось к sdg), поэтому на этот раз я заранее удалил битовую карту записи, но это не помогло.
Плата (ASRock P67 Extreme6) имеет странно неоднородное SATA-обеспечение с двумя портами SATA3 и шестью портами SATA6 (два от чипсета и четыре от встроенного интерфейса Marvell SE9120). Возможно, что sdg находится на порте, который также используется совместно с сокетом eSATA, но он утверждает, что использует UDMA6, как и другие, поэтому я не вижу, какой эффект это даст.
Есть идеи, почему tps (IOPS) на SDG вдвое больше других?
ОБНОВЛЕНИЕ: дальнейшее уточнение:
Накопителям 3 года Seagate Barracudas 3 ТБ (хотя я обычно не связываюсь с анекдотами бренда накопителя, один из 8 дисков вышел из строя, а три других (но не sdg) показывают плохие признаки (неисправимые ошибки, множественные ошибки). перераспределенные сектора): это не самые надежные диски, которые я когда-либо использовал). "Я уверен, что они скучные PMR.
Как только RAID был восстановлен, доступ теперь распределяется равномерно между всеми дисками с одинаковым количеством операций ввода-вывода в секунду для каждого диска. Таким образом, я был бы удивлен, если скорость соединения была релевантной (хотя md мог делать странные "оптимизации", я полагаю).
У меня не было возможности получить вывод "iostat x" до того, как RAID завершил восстановление, но из памяти sdg использовался на 100% и имел большой размер очереди запросов (в сотнях секунд), в то время как другие были загружены на 50-60% и имели размер очереди запросов, состоящий из одной цифры.
Я думаю, мне нужно было бы поменять местами sdg и другой диск, чтобы полностью исключить, является ли это контроллер / md или диск.
ОБНОВЛЕНИЕ № 2: Различные перестроения, та же проблема
На этот раз я восстанавливаю SDB:
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 13813.00 0.00 184.50 0.00 54.06 0.00 600.11 23.60 114.11 114.11 0.00 2.49 46.00
sdb 0.00 12350.50 0.00 97.50 0.00 48.62 1021.37 0.17 1.70 0.00 1.70 1.31 12.80
sdd 12350.00 0.00 98.00 0.00 48.62 0.00 1016.16 5.47 55.82 55.82 0.00 2.82 27.60
sdc 12350.00 0.00 98.00 0.00 48.62 0.00 1016.16 5.92 60.41 60.41 0.00 2.84 27.80
sde 12350.00 0.00 98.00 0.00 48.62 0.00 1016.16 6.11 62.39 62.39 0.00 3.02 29.60
sdf 12350.50 0.00 97.50 0.00 48.62 0.00 1021.37 14.56 149.33 149.33 0.00 3.92 38.20
sdg 12350.00 0.00 98.00 0.00 48.62 0.00 1016.16 7.18 73.31 73.31 0.00 3.16 31.00
sdh 12350.00 0.00 98.00 0.00 48.62 0.00 1016.16 5.27 53.80 53.80 0.00 2.88 28.20
Как вы можете видеть, sda получает намного больше доступа, чем другие (я ограничиваю его, чтобы sda не достигла 100% -ной загрузки, хотя будет, если я этого не сделаю). Интересно, что "avgrq-sz" (средний размер запроса) sda ниже, что говорит о том, что дополнительный доступ намного меньше. Теперь мне просто нужно найти способ разобраться, что они из себя представляют!
1 ответ
Мое первоначальное предположение было, что md
определили проблему с sdg
и пытался извлечь данные из него "раньше", чтобы его тоже можно было заменить.
Это не так md
работает, хотя (некоторые аппаратные контроллеры могут сделать это - не уверены).
Множество дисков в массиве замедляют перестройку ( pdf) - с точки зрения перестройки, меньше дисков в массиве "лучше".
Дальнейшее изучение приводит как к возможному выводу, так и к нескольким последующим вопросам:
- какого размера диски?
- какого типа они - корпоративные или настольные?
- какой марки они - WD, Seagate, Hitachi, другие, микс?
- какой тип дисков в массиве - PMR или SMR?
Из этого обзора диска Seagate видно, что восстановление с использованием SMR (которые более плотно упакованы) дисков необычно несовместимы по скорости, в то время как PMR более согласован.
Мой предварительный вывод заключается в том, что
- разные скорости порта SATA здесь не помогают - это, я думаю, должно быть очевидно для всех участников:)
- в массиве либо диски другой марки, либо они очень большие, либо они не предназначены для " лучшей" перестройки (PMR) - либо сочетания вышеперечисленного