У нас есть сервер RHEL 5.6 с 4 активными путями к одному LUN. Мы подозреваем, что он не может втиснуть достаточно операций ввода-вывода по конвейеру до XIV на другом конце:
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
Похоже, что RHEL должен иметь возможность отправлять гораздо больше операций ввода-вывода в секунду по каждому пути (что желательно для подсистемы хранения XIV), но% util на устройстве dm-9 (которое является многопутевой картой) находится примерно на 100%.
Означает ли это, что RHEL не может втиснуть какие-либо операции ввода-вывода в секунду в многопутевую передачу (и, следовательно, узким местом является RHEL)? Как мне это интерпретировать?
Как получить 99,54% из 37,50, 38,06, 37,47, 40,74 на отдельных дисках?
Эксперименты, похоже, подтверждают, что время, потраченное ядром на ожидание завершения записи для синхронизации, засчитывается в% занятости.
Итак, рабочая нагрузка этого конкретного приложения (DB2 с синхронным журналом аудита) выполняла:
в журнал аудита по каждой проверенной деятельности. Который УБИЛ производительность.
Кажется, все с настройкой DM в порядке, также iostat вывод выглядит совершенно вменяемым. 1500 IOPS - это почти ничто для DM и арахисовая нагрузка для XIV. Вам нужно поискать в другом месте.