Назад | Перейти на главную страницу

Один диск обращался больше, чем другие во время восстановления md RAID6

Я восстанавливаю один диск из 8-дискового RAID6 (с использованием программного RAID-массива Linux 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, чтобы добавить заменяющий диск, отказав / удалив существующий).

Вещи, которые (я думаю) я исключил:

  1. Все диски имеют одинаковую схему разделов (скопированы с помощью sgdisk).

  2. sda-sdg - это идентичные диски с тем же номером модели (sdh новый).

  3. Я посмотрел на опережение чтения, размер блока, multcount на всех дисках и не заметил никакой разницы, которая могла бы быть у sdp по сравнению с другими.

  4. Другая перестройка на том же компьютере имела ту же проблему (доступ к sdg увеличивался), поэтому на этот раз я удалил растровое изображение намерения записи заранее, но это не помогло.

  5. На плате (ASRock P67 Extreme6) имеется странно неоднородное устройство SATA с двумя портами SATA3 и шестью портами SATA6 (два от чипсета и четыре от встроенного интерфейса Marvell SE9120). Возможно, что sdg находится на порту, который также используется совместно с сокетом eSATA, но он утверждает, что использует UDMA6, как и другие, поэтому я не вижу, какой эффект это будет иметь.

Любые идеи, почему tps (IOPS) на SDG в два раза больше других?

ОБНОВЛЕНИЕ: дополнительные пояснения:

  1. Это 3-летние диски Seagate Barracudas емкостью 3 ТБ (хотя я обычно не ввязываюсь в анекдоты о брендах дисков, один из 8 дисков вышел из строя, а три других (но не sdg) имеют плохие признаки (неисправимые ошибки, несколько перераспределенные секторы): это не самые надежные диски, которые я когда-либо использовал). `` Я почти уверен, что они утомляют PMR.

  2. После восстановления RAID доступ равномерно распределяется между всеми дисками с одинаковым количеством операций ввода-вывода в секунду для каждого диска. Таким образом, я был бы удивлен, если бы скорость соединения имела значение (хотя я полагаю, что md может делать странные «оптимизации»).

  3. У меня не было возможности получить вывод '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 ниже, что говорит о том, что дополнительные обращения намного меньше. Теперь мне просто нужно найти способ выяснить, что это такое!

Моя первоначальная догадка заключалась в том, что md обнаружил проблему с sdg, и пытался извлечь из него данные «раньше», чтобы их тоже можно было заменить.

Это не как md работает, хотя (некоторые аппаратные контроллеры могут это делать - не уверен).

Большое количество дисков в массиве замедляет восстановление (pdf) - из перестроить В перспективе меньшее количество дисков в массиве - «лучше».

Дальнейшее исследование приводит как к возможному выводу, так и к нескольким следующим вопросам:

  • какого размера диски?
  • какого они типа - корпоративные или настольные?
  • какой они марки - WD, Seagate, Hitachi, другие, микс?
  • какие диски в массиве - PMR или SMR?

Из этого обзор диска Seagate кажется, что он перестраивается с SMR (которые плотнее упакованный) диски необычно непостоянны по скорости, тогда как PMR более постоянен.

Мой предварительный вывод заключается в том, что

  1. разные скорости порта SATA здесь не помогают - это, я думаю, должно быть очевидно для всех участников :)
  2. у вас в массиве либо диски других марок, либо они очень большие, либо они не предназначены для восстановления "лучше"(PMR) - или сочетание вышеперечисленного