Почему для устройства многолучевого распространения DM больше время ожидания, чем для базового устройства?

У нас есть сервер на базе CentOS 6.4, подключенный к хранилищу Hitachi HNAS 3080, и мы наблюдали, как ядро перемонтирует файловую систему в режиме только для чтения:

16 мая 07:31:03 Ядро GNS3-SRV-CMP-001: [1259725.675814] EXT3-fs (dm-1): ошибка: перемонтирование файловой системы только для чтения

Это произошло после нескольких ошибок ввода-вывода и всех путей к устройству, которые, по сообщениям, перестали работать:

16 мая 07:31:03 GNS3-SRV-CMP-001 multiathd: mpatha: оставшиеся активные пути: 0

Я просматривал журналы sar и вижу несколько очень больших (2 секунды) раз ожидания:

07:40:00       dev8-0     17.91    112.04     98.03     11.73      0.00      0.20      0.07      0.12
07:40:00      dev8-16      0.23      1.85      0.00      8.00      0.00      3.71      3.71      0.09
07:40:00      dev8-32     91.50   8338.76   5292.93    148.98      8.38     91.60      9.76     89.35
07:40:00     dev252-0     91.27   8336.91   5292.93    149.34     17.79    194.88      9.79     89.38
07:40:00     dev252-1    674.80   8168.16   5292.93     19.95   1473.53   2183.60      1.32     88.98

Продолжительность между 07: 30: 00-07: 40: 00 действительно происходит, когда файловая система монтируется только для чтения. Однако даже при нормальных условиях одно повторное наблюдение состоит в том, что время ожидания для базовых устройств намного меньше, чем для многолучевого устройства. Например:

00:00:00          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
00:10:00       dev8-0     19.27    129.41     78.61     10.80      0.01      0.27      0.16      0.32
00:10:00      dev8-16      0.23      1.80      0.00      8.00      0.00      0.86      0.84      0.02
00:10:00      dev8-32     94.88  10285.16   3363.48    143.86      3.39     35.76      6.83     64.82
00:10:00     dev252-0     94.65  10283.34   3363.48    144.18      3.64     38.47      6.86     64.89
00:10:00     dev252-1    435.06  10087.12   3363.48     30.92    118.42    272.21      1.47     64.12

dev8-0 является локальным диском, а dev8-16 ( /dev/sdb) и dev8-32 ( /dev/sdc) являются базовыми для dev252-0 ( /dev/mapper/mpatha). dev252-1 ( /dev/mapper/mpathap1) - это один раздел, охватывающий все многолучевое устройство. Вот вывод из multipath -ll:

mpatha (2521501cbffffffffe96773b50ec30020) dm-0 BlueArc,NAS Platform
size=10T features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 9:0:0:0 sdc 8:32 active ready running
`-+- policy='round-robin 0' prio=1 status=active
  `- 8:0:0:0 sdb 8:16 active ready running

Почему время ожидания должно /dev/mapper/mpathap1быть намного выше, чем время /dev/mapper/mpathaили даже /dev/sdbили /dev/sdc?

performance iowait device-mapper

— ПРП
источник

Кажется , следует отметить , что , по- видимому много запросов слияния происходит на пути от /dev/mapper/mpathap1к /dev/mapper/mpatha. Это также слой, где большую часть awaitвремени кажется добавленным. Можете ли вы проверить, какие лифты используются /sys/block/mpathap1/queue/schedulerи /sys/block/mpatha/queue/scheduler, возможно, переключаться на них deadlineили noopдля сравнения?

— the-wabbit

Планировщик ввода / вывода для mpatha( /sys/block/dm-0/queue/scheduler) есть, noopа для mpathap1( /sys/block/dm-1/queue/scheduler) есть none.

— pdp

Я сильно подозреваю, что за задержку отвечает алгоритм очередей / слияния планировщика. Я бы поменял cfq базовых устройств на noop или дедлайн, чтобы посмотреть, изменится ли он. Это, вероятно, не будет связано с вашей проблемой всех путей вниз, хотя.

— the-wabbit

FWIW, я наблюдал такое же поведение на других типах устройств отображения устройств - особенно с пулами NSS . Записи с возможностью слияния имеют более высокое ожидание (и более длинные очереди) на dmустройстве, чем на базовом физическом устройстве, в то время как запросы на чтение и записи без какого-либо слияния, в основном, не затрагиваются. Я пока не знаю, является ли это просто ошибкой представления из-за того, как рассчитываются ожидающие данные, или фактически увеличенным временем отклика из-за характера алгоритма организации очередей / объединения.

— The Wabbit

Один из сценариев ввода-вывода Systemtap может дать вам дополнительное понимание того, что происходит. io_submit.stp, ioblktime.stp и biolatency-nd.stp могут быть хорошими местами для начала.

— Кассандри

Как предполагает пользователь the-wabbit, происходит слияние запросов. Вы можете видеть, что в столбце avgrq-sz средний размер запроса - который показывает значительное увеличение.

Теперь «ожидание» - это время, проведенное в очереди, плюс время, затраченное на обслуживание этих запросов. Если небольшой запрос, назовем его «x», объединится с парой других запросов (y и z, выданных после x), то x будет

ждать в очереди для объединения с
подождите в очереди, чтобы слиться с z
дождитесь завершения (x, y, z)

Это, очевидно, окажет негативное влияние на статистику ожидания, главным образом из-за того, как рассчитывается ожидание, фактически не обозначая проблему само по себе.

Теперь давайте посмотрим на / dev / sdb (dev8-16). Знаете ли вы, что вы не используете этот путь? У вас есть две приоритетные группы в конфигурации с несколькими путями, одна

статус = включено

и на это

Статус = активный

У вас наверное есть

path_grouping_policy аварийное переключение

в вашей конфигурации (которая используется по умолчанию).

Если вы хотите предотвратить ошибки ввода-вывода в случае, если оба пути не работают, вы можете попробовать:

        функции "1 queue_if_no_path"

в вашем multipath.conf

Теперь реальный вопрос остается, почему оба пути идут вниз?

— отдаленный разум
источник