Por que maior tempo de espera para o dispositivo multipath DM que o dispositivo subjacente?

Question

Temos um servidor baseado no CentOS 6.4 conectado ao armazenamento Hitachi HNAS 3080 e observamos o kernel remontar o sistema de arquivos no modo somente leitura:

May 16 07:31:03 GNS3-SRV-CMP-001 kernel: [1259725.675814] EXT3-fs (dm-1): error: remounting filesystem read-only

Isso aconteceu depois de vários erros de E / S e todos os caminhos para o dispositivo terem diminuído:

May 16 07:31:03 GNS3-SRV-CMP-001 multipathd: mpatha: remaining active paths: 0

Eu tenho visto os logs do sar e posso ver alguns muito grandes (2 segundos) aguardando:

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

A duração entre 07: 30: 00-07: 40: 00 acontece na hora em que o sistema de arquivos foi montado como somente leitura. No entanto, mesmo sob condições normais, uma observação repetida é que o tempo de espera para os dispositivos subjacentes é muito menor do que o do dispositivo multipercurso. Por exemplo:

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 é o disco local, enquanto dev8-16 ( /dev/sdb ) e dev8-32 ( /dev/sdc ) são os subjacentes para dev252-0 ( /dev/mapper/mpatha ). dev252-1 ( /dev/mapper/mpathap1 ) é uma partição única que abrange todo o dispositivo multipath. Aqui está a saída 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 que o tempo de espera de /dev/mapper/mpathap1 deve ser muito superior ao de /dev/mapper/mpatha ou mesmo /dev/sdb ou /dev/sdc ?

    

Answer 1

Como o usuário the-wabbit sugere, há uma fusão de pedidos acontecendo. Você pode ver isso na coluna avgrq-sz, o tamanho médio da solicitação - que mostra um aumento significativo.

Agora, 'aguardar' é o tempo gasto na fila mais o tempo gasto atendendo a essas solicitações. Se um pequeno pedido, vamos chamá-lo de 'x', é mesclado com um par de outros pedidos (y e z, emitidos após x), então x irá

• espera na fila para ser mesclado com y
• espere na fila para ser mesclado com z
• espere que (x, y, z) seja concluído

Isso obviamente terá um impacto negativo na estatística await, principalmente por causa do cálculo da espera, sem realmente significar um problema em si.

Agora vamos dar uma olhada em / dev / sdb (dev8-16). Você sabia que não está usando esse caminho? Você tem dois grupos de prioridade na configuração do seu multipath, um é

status=enabled

e on é

status=active

Você provavelmente tem

path_grouping_policy    failover

na sua configuração (que é o padrão).

Se você quiser evitar os erros de E / S no caso de ambos os caminhos estarem inativos, tente:

        features        "1 queue_if_no_path"

no seu multipath.conf

Agora, a verdadeira questão permanece: por que ambos os caminhos caem?