¿Por qué un mayor tiempo de espera para el dispositivo DM multirruta que el dispositivo subyacente?

Tenemos un servidor basado en CentOS 6.4 conectado al almacenamiento Hitachi HNAS 3080 y observamos que el núcleo vuelve a montar el sistema de archivos en modo de solo lectura:

16 de mayo 07:31:03 GNS3-SRV-CMP-001 kernel: [1259725.675814] EXT3-fs (dm-1): error: remontando el sistema de archivos de solo lectura

Esto sucedió después de varios errores de E / S y, según los informes, todas las rutas al dispositivo se cayeron:

16 de mayo 07:31:03 GNS3-SRV-CMP-001 multipathd: mpatha: rutas activas restantes: 0

He estado mirando los registros de sar y puedo ver algunos tiempos de espera muy grandes (2 segundos):

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 duración entre 07: 30: 00-07: 40: 00 sucede el momento en que el sistema de archivos se montó de solo lectura. Sin embargo, incluso en condiciones normales, una observación repetida es que el tiempo de espera para los dispositivos subyacentes es mucho menor que el del dispositivo multirruta. Por ejemplo:

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 es el disco local, mientras que dev8-16 ( /dev/sdb) y dev8-32 ( /dev/sdc) son los subyacentes para dev252-0 ( /dev/mapper/mpatha). dev252-1 ( /dev/mapper/mpathap1) es una única partición que abarca todo el dispositivo de múltiples rutas. Aquí está la salida de 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

¿Por qué el tiempo de espera para /dev/mapper/mpathap1ser mucho mayor que el de /dev/mapper/mpathao incluso /dev/sdbo /dev/sdc?

performance iowait device-mapper

— pdp
fuente

Parece digno de mención que, aparentemente, está ocurriendo una gran cantidad de solicitudes en el camino desde el /dev/mapper/mpathap1hasta /dev/mapper/mpatha. Esta es también la capa donde la mayoría de las awaitveces parece agregarse. ¿Puede verificar en qué ascensores se utilizan /sys/block/mpathap1/queue/schedulery /sys/block/mpatha/queue/scheduler, posiblemente, cambiarlo deadlineo noopcompararlo?

— the-wabbit

El planificador de E / S para mpatha( /sys/block/dm-0/queue/scheduler) es noopy el de mpathap1( /sys/block/dm-1/queue/scheduler) es none.

— pdp

Sospecho firmemente que el algoritmo de cola / fusión del planificador es responsable del retraso. Cambiaría cfq de los dispositivos subyacentes por noop o fecha límite solo para ver si cambia algo. Sin embargo, esto probablemente no esté relacionado con su problema de todos los caminos hacia abajo.

— the-wabbit

FWIW, he observado el mismo tipo de comportamiento en otros tipos de dispositivos de mapeo de dispositivos, específicamente con los grupos NSS . Las escrituras que se pueden combinar tienen una mayor espera (y colas más largas) en el dmdispositivo que en el dispositivo físico subyacente, mientras que las solicitudes de lectura y las escrituras sin ninguna fusión realizada no se ven afectadas principalmente. Todavía no sé si esto es simplemente un error de presentación debido a la forma en que se calculan las esperas o los tiempos de respuesta prolongados debido a la naturaleza del algoritmo de cola / fusión.

— the-wabbit

Uno de los scripts de Systemtap IO podría proporcionarle información adicional sobre lo que está sucediendo. io_submit.stp, ioblktime.stp y biolatency-nd.stp pueden ser buenos lugares para comenzar.

— Kassandry

Como sugiere el usuario the-wabbit, hay una fusión de solicitudes en curso. Puede ver que en la columna avgrq-sz, el tamaño promedio de la solicitud, que muestra un aumento significativo.

Ahora 'esperar' es el tiempo que se pasa en la cola más el tiempo que se pasa atendiendo esas solicitudes. Si una pequeña solicitud, llamémosla 'x', se fusiona con un par de otras solicitudes (y y z, emitidas después de x), entonces x será

esperar en la cola para fusionarse con y
espera en la cola para ser fusionado con z
espera a que se complete (x, y, z)

Obviamente, esto tendrá un impacto negativo en la estadística de espera, principalmente debido a la forma en que se calcula la espera, sin significar realmente un problema en sí mismo.

Ahora echemos un vistazo a / dev / sdb (dev8-16). ¿Sabías que no estás usando ese camino? Tiene dos grupos de prioridad en su configuración de múltiples rutas, uno es

estado = habilitado

y en es

estado = activo

Probablemente tienes

path_grouping_policy failover

en su configuración (que es la predeterminada).

Si desea evitar los errores de E / S en caso de que ambas rutas estén inactivas, puede intentar:

        cuenta con "1 queue_if_no_path"

en su multipath.conf

Ahora la verdadera pregunta sigue siendo, ¿por qué ambos caminos bajan?

— mente remota
fuente