Perché tempi di attesa più lunghi per il dispositivo multipath DM rispetto al dispositivo sottostante?

Abbiamo un server basato su CentOS 6.4 collegato allo storage Hitachi HNAS 3080 e abbiamo osservato che il kernel ha rimontato il filesystem in modalità di sola lettura:

16 maggio 07:31:03 kernel GNS3-SRV-CMP-001: [1259725.675814] EXT3-fs (dm-1): errore: rimontaggio file system di sola lettura

Ciò è accaduto dopo diversi errori di I / O e tutti i percorsi verso il dispositivo sono in calo:

16 maggio 07:31:03 GNS3-SRV-CMP-001 multipathd: mpatha: rimanenti percorsi attivi: 0

Ho guardato i registri sar e vedo pochi tempi di attesa molto grandi (2 secondi):

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

La durata tra 07: 30: 00-07: 40: 00 si verifica nel momento in cui il filesystem è stato montato in sola lettura. Tuttavia, anche in condizioni normali, un'osservazione ripetuta è che il tempo di attesa per i dispositivi sottostanti è molto inferiore a quello del dispositivo multipath. Per esempio:

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 sembra essere il disco locale, mentre dev8-16 ( /dev/sdb) e dev8-32 ( /dev/sdc) sono quelli sottostanti per dev252-0 ( /dev/mapper/mpatha). dev252-1 ( /dev/mapper/mpathap1) è una singola partizione che copre l'intero dispositivo multipath. Ecco l'output di 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

Perché il tempo di attesa dovrebbe /dev/mapper/mpathap1essere molto più alto di quello di /dev/mapper/mpathao anche /dev/sdbo /dev/sdc?

performance iowait device-mapper

— pdp
fonte

Sembra degno di nota che apparentemente molte richieste di fusione si stanno verificando sulla strada da /dev/mapper/mpathap1a /dev/mapper/mpatha. Questo è anche il livello in cui la maggior parte delle awaitvolte sembra essere stata aggiunta. Puoi controllare in quali ascensori vengono utilizzati /sys/block/mpathap1/queue/schedulere /sys/block/mpatha/queue/scheduler, eventualmente, commutarlo deadlineo noopconfrontarlo?

— the-wabbit,

Lo scheduler I / O per mpatha( /sys/block/dm-0/queue/scheduler) è noope quello per mpathap1( /sys/block/dm-1/queue/scheduler) è none.

— pdp,

Sospetto fortemente che l'algoritmo di accodamento / fusione dello schedulatore sia responsabile del ritardo. Vorrei scambiare cfq dei dispositivi sottostanti con noop o scadenza solo per vedere se cambia qualcosa. Questo probabilmente non sarà correlato al problema di tutti i percorsi verso il basso.

— the-wabbit il

FWIW, ho osservato lo stesso tipo di comportamento su altri tipi di dispositivi mapper dispositivo, in particolare con pool NSS . Le scritture in grado di unire hanno un'attesa più elevata (e code più lunghe) sul dmdispositivo rispetto al dispositivo fisico sottostante, mentre le richieste di lettura e le scritture senza alcuna fusione eseguite non sono interessate. Non so ancora se questo è semplicemente un errore di presentazione dovuto al modo in cui vengono calcolate le attese o ai tempi di risposta effettivamente prolungati a causa della natura dell'algoritmo di accodamento / fusione.

— the-wabbit

Uno degli script Systemtap IO potrebbe fornire ulteriori informazioni su ciò che sta accadendo. io_submit.stp, ioblktime.stp e biolatency-nd.stp potrebbero essere dei buoni punti di partenza.

— Kassandry,

Come suggerisce l'utente the-wabbit, c'è una fusione di richieste in corso. Puoi vedere che nella colonna avgrq-sz, la dimensione media della richiesta - che mostra un aumento significativo.

Ora "wait" è il tempo impiegato nella coda più il tempo dedicato a soddisfare tali richieste. Se una piccola richiesta, chiamiamola "x", viene unita a un paio di altre richieste (y e z, emesse dopo x), allora x sarà

attendere in coda per essere uniti a y
attendere in coda per essere unito a z
attendere che (x, y, z) sia completato

Ciò avrà ovviamente un impatto negativo sulla statistica di attesa, principalmente a causa del modo in cui viene calcolata l'attesa, senza effettivamente significare un problema in sé.

Ora diamo un'occhiata a / dev / sdb (dev8-16). Sapevi che non stai usando quel percorso? Hai due gruppi prioritari nella tua configurazione multipath, uno è

status = abilitato

e via è

lo stato attivo =

Probabilmente hai

failover path_grouping_policy

nella tua configurazione (che è l'impostazione predefinita).

Se si desidera prevenire gli errori di I / O nel caso in cui entrambi i percorsi siano inattivi, è possibile provare:

        dispone di "1 queue_if_no_path"

nel tuo multipath.conf

Ora la vera domanda rimane, perché entrambi i percorsi scendono?

— mente remota
fonte