Чому на багатошаровий пристрій 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 багатодоріжка: 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

— pdp
джерело

Здається примітним, що, мабуть, багато об'єднань запитів відбувається на шляху від /dev/mapper/mpathap1до /dev/mapper/mpatha. Це також шар, на який, awaitздається, додається більшість часу. Чи можете ви перевірити, які ліфти використовуються /sys/block/mpathap1/queue/schedulerта /sys/block/mpatha/queue/scheduler, можливо, переключити їх на порівняння deadlineчи noopпорівняти їх?

— ваббіт

Планувальник введення / виведення для 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 можуть бути хорошими місцями для початку.

— Кассандрі

Як підказує користувач-wabbit, відбувається злиття запитів. Ви можете бачити, що у стовпчику avgrq-sz середній розмір запиту - який показує значне збільшення.

Тепер "очікувати" - це час, витрачений у черзі плюс час, витрачений на обслуговування цих запитів. Якщо невеликий запит, назвемо його "x", об'єднується з парою інших запитів (y і z, виданих після x), x

зачекайте в черзі, щоб злитися з у
зачекайте в черзі tu злиття з z
зачекайте завершення (x, y, z)

Це, очевидно, матиме негативний вплив на статистику очікування, здебільшого через те, як обчислюється спосіб очікування, не означаючи фактично проблеми.

Тепер давайте подивимось на / dev / sdb (dev8-16). Чи знали ви, що не використовуєте цей шлях? Ви маєте дві групи пріоритетів у конфігурації багатошлях, одна є

статус = увімкнено

і на є

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

Ви, мабуть, є

аварійний збір шляху_групіровки_поліції

у вашій конфігурації (яка за замовчуванням).

Якщо ви хочете попередити помилки вводу-виводу у випадку, якщо обидва шляху пропущені, ви можете спробувати:

        має "1 чергу_if_no_path"

у вашому multipath.conf

Тепер залишається справжнє питання, чому обидві стежки йдуть вниз?

— віддалений розум
джерело