Temos aqui um servidor RHEL 5.6 com 4 caminhos ativos para um único LUN. Nós suspeitamos que não é capaz de enfiar IOs o suficiente para o XIV do outro lado:
mpath0 (XXXXXXXXXXXXXXX) dm-9 IBM,2810XIV
[size=1.6T][features=1 queue_if_no_path][hwhandler=0][rw]
\_ round-robin 0 [prio=4][active]
\_ 2:0:1:2 sdaa 65:160 [active][ready]
\_ 1:0:0:2 sdc 8:32 [active][ready]
\_ 1:0:1:2 sdk 8:160 [active][ready]
\_ 2:0:0:2 sds 65:32 [active][ready]
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdc 0.00 108.18 49.30 273.65 795.21 1527.35 14.38 0.49 1.51 1.16 37.50
sdk 0.00 101.00 49.70 280.44 1700.60 1525.75 19.55 0.55 1.67 1.15 38.06
sds 0.20 110.58 50.10 270.26 1287.82 1523.35 17.55 0.51 1.58 1.17 37.47
sdaa 0.00 99.60 46.31 285.23 781.64 1539.32 14.00 0.56 1.68 1.23 40.74
dm-9 0.00 0.00 195.61 1528.94 4565.27 6115.77 12.39 2.52 1.46 0.58 99.54
Parece que o RHEL pode enviar muito mais IOPS em cada caminho (o que é desejável no subsistema de armazenamento XIV), mas o% util no dispositivo dm-9 (que é o mapa multipath) está por aí 100%.
Isso significa que o RHEL não é capaz de empilhar qualquer IOPS no multipath (e, portanto, o gargalo é o RHEL)? Como devo interpretar isso?
Como obtemos 99,54% de 37,50, 38,06, 37,47 e 40,74 em discos individuais?
As experiências parecem confirmar que o tempo gasto pelo kernel aguardando uma gravação sincronizada é contado em relação ao% ocupado.
Portanto, a carga de trabalho desse aplicativo específico (o DB2 com o log de auditoria síncrona) estava sendo feita:
para o log de auditoria em todas as atividades auditadas. Qual performance KILLED.
Tudo com sua configuração do DM parece estar bem, também a saída iostat parece totalmente sensata. 1500 IOPS são quase nada para DM e carga de amendoim para o XIV. Você precisa procurar em outro lugar.