Почему для устройства с многолучевым распространением 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?
1 ответ
Как предполагает пользователь 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
Теперь реальный вопрос остается, почему оба пути идут вниз?