Постоянно tm_act 100% для одного диска в AIX 6.1

[Дмитрий]

Всем привет. Возникла небольшая проблема и некое непонимание.
Имеем AIX 6100-02-10-1036, DS8k, SDDPCM VERSION 2.6.0.3. Используется NPIV. Железо – p780.

Сама проблема и непонимание почему так: настораживает 100% загрузка диска.

Ниже часть вывода iostat -md hdisk11 1:
[code]
Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk11 100.0 8056.0 873.0 5400 2656

Paths: % tm_act Kbps tps Kb_read Kb_wrtn
Path7 52.0 2240.0 239.0 1424 816
Path6 56.0 2168.0 236.0 1368 800
Path5 63.0 1696.0 198.0 1288 408
Path4 54.0 1976.0 203.0 1344 632

Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk11 100.1 6444.3 805.5 6440 0

Paths: % tm_act Kbps tps Kb_read Kb_wrtn
Path7 76.1 1617.1 202.1 1616 0
Path6 71.0 1585.1 198.1 1584 0
Path5 70.0 1697.1 212.1 1696 0
Path4 72.0 1553.0 194.1 1552 0

Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk11 99.8 32603.9 4004.7 30760 1920

Paths: % tm_act Kbps tps Kb_read Kb_wrtn
Path7 83.8 8292.7 1014.6 7840 472
Path6 91.8 7933.5 972.7 7392 560
Path5 88.8 8101.1 990.7 7672 448
Path4 87.8 8260.7 1024.6 7840 440

Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk11 99.7 34548.4 4318.0 34640 12

Paths: % tm_act Kbps tps Kb_read Kb_wrtn
Path7 92.7 8781.7 1097.7 8808 0
Path6 91.7 8143.6 1017.9 8168 0
Path5 93.7 8689.9 1085.7 8704 12
Path4 89.7 8965.1 1120.6 8992 0
[/code]
Кусок вывода iostat -D:
[code]
——————————————————————————–
hdisk11 xfer: %tm_act bps tps bread bwrtn
91.5 6.0M 721.7 5.7M 309.4K
read: rps avgserv minserv maxserv timeouts fails
697.8 2.3 0.2 52.6 0 0
write: wps avgserv minserv maxserv timeouts fails
23.9 0.3 0.3 1.0 0 0
queue: avgtime mintime maxtime avgwqsz avgsqsz sqfull
0.0 0.0 0.1 0.0 1.0 0.0
——————————————————————————–
hdisk11 xfer: %tm_act bps tps bread bwrtn
99.2 6.7M 815.2 6.7M 48.7K
read: rps avgserv minserv maxserv timeouts fails
812.2 3.6 0.2 52.6 0 0
write: wps avgserv minserv maxserv timeouts fails
3.0 0.4 0.3 1.0 0 0
queue: avgtime mintime maxtime avgwqsz avgsqsz sqfull
0.0 0.0 0.1 0.0 3.0 0.0
——————————————————————————–
hdisk11 xfer: %tm_act bps tps bread bwrtn
99.8 6.6M 790.7 6.3M 368.0K
read: rps avgserv minserv maxserv timeouts fails
764.7 3.7 0.2 52.6 0 0
write: wps avgserv minserv maxserv timeouts fails
26.0 0.3 0.3 1.0 0 0
queue: avgtime mintime maxtime avgwqsz avgsqsz sqfull
0.0 0.0 0.1 0.0 2.0 0.0
——————————————————————————–
hdisk11 xfer: %tm_act bps tps bread bwrtn
100.0 8.0M 966.3 7.8M 172.1K
read: rps avgserv minserv maxserv timeouts fails
954.3 3.7 0.2 52.6 0 0
write: wps avgserv minserv maxserv timeouts fails
12.0 0.4 0.2 1.0 0 0
queue: avgtime mintime maxtime avgwqsz avgsqsz sqfull
0.0 0.0 0.1 0.0 3.0 0.0
——————————————————————————–
[/code]
Вывод vmstat вроде в порядке:
[code]
System configuration: lcpu=30 mem=73728MB ent=15.00

kthr memory page faults cpu
——- ——————— ———————————— —————— ———————–
r b avm fre re pi po fr sr cy in sy cs us sy id wa pc ec
14 0 5107737 756969 0 0 0 0 0 0 7151 118371 17645 51 3 41 5 9.74 65.0
18 0 5130995 733715 0 0 0 0 0 0 8555 132706 21004 53 4 39 4 9.97 66.5
0 0 5087402 777308 0 0 0 0 0 0 5517 83507 11952 47 3 41 10 8.98 59.9
5 0 5091520 773190 0 0 0 0 0 0 6355 112076 14724 28 3 62 7 5.81 38.7
6 0 5055743 808967 0 0 0 0 0 0 6752 112838 15443 35 3 57 5 7.01 46.8
8 0 5055706 809004 0 0 0 0 0 0 7003 115331 15116 25 3 66 5 5.19 34.6
11 0 5056990 807720 0 0 0 0 0 0 6602 113049 14578 30 3 60 7 5.99 39.9
9 0 5057172 807538 0 0 0 0 0 0 6147 111495 12217 30 3 65 3 6.00 40.0
10 0 5057618 807092 0 0 0 0 0 0 6985 166802 14830 35 3 57 4 6.89 45.9
8 0 5056949 807761 0 0 0 0 0 0 5925 118438 12985 32 3 61 4 6.37 42.5
[/code]
IO wait в районе 7-8% в среднем, это нормально?

Для всех FC адаптеров на хосте, стоят параметры: lg_term_dma=0x800000, max_xfer_size=0x100000, num_cmd_elems=2048. Очереди к дискам – 64. До этого было 20, ничего не изменилось по загруженности диска, но sqfull ушла в ноль.

На VIOS (да и на хосте) на всех FC адаптерах fcstat показывает:
FC SCSI Adapter Driver Information
No DMA Resource Count: 0
No Adapter Elements Count: 0
No Command Resource Count: 0

Видимо, с параметрами fcs проблем нет тоже.

# pcmpath query devstats 11
[code]
DEV#: 11 DEVICE NAME: hdisk11
===============================
Total Read Total Write Active Read Active Write Maximum
I/O: 35582326 3761315 3 0 64
SECTOR: 1694268569 587917072 48 0 28000

Transfer Size: <= 512 <= 4k <= 16K <= 64K > 64K
231 501 32073969 2083518 5185422
[/code]
К сожалению, информации о конфигурации СХД пока нет, но могу постараться достать. Знающие люди советуют раздобыть showfbvol -metrics и showextpool -metrics для LUN и пула в котором этот LUN. Может быть что-то еще?

[andrewk]

а почему Вас это беспокоит? 🙂 Диск работает, iowait до 20% в принципе нормально. Пользователи пожаловались, что приложение стало тормозить? Поищите, кто так активно пишет на этот диск (filemon), возможно стоит из одного диска сделать два, или перенести какую-то нагрузку на другой, менее загруженный диск

[Дмитрий]

Началось все с того, что прикладники получали письмо от нотификатора Оракла следующего вида:
Occurred At=16.11.2011 15:01:58 MSK
Message=Disk Device hdisk11 is 96,63% busy.
Metric=Disk Device Busy (%)
Metric value=96.63
Disk Device=hdisk11
Severity=Critical
Acknowledged=No
Notification Rule Name=EOSDO_Host
Notification Rule Owner=SYSMAN

Стали смотреть – и правда. Жалоб вроде никаких нет, но нагрузка постоянно растет и кто знает, что будет дальше. Плюс ко всему – смущает эти 100%, хоть и IO wait весьма малы.
Больше всего непонятно почему по каждому пути в отдельности бывает около 50-60%, а суммарно на диск все равно 100%. Видимо, я что-то не понимаю. Собственно, захотелось понять и разобраться.

[Ivan]

%tm_act – это % времени которое том был активен.
Если большие очереди на томах и адаптерах, значение в колонке b вывода vmstat большие (значительно больше) устройств ввода вывода (путей), высокие значения wa (однако, в некоторых случаях по высокому значению wa нельзя говорить о проблемах в IO), то можно говорить что где-то проблемы.
imho, busy ~100% не говорит о полной загрузке дисковой подсистемы.
В приложенном выводе проблем, imho, нет (смешные нагрузки для такого массива).

[Александр Фролушкин]

У меня периодически бывает на разделах 100% busy, лечится перезагрузкой. Судя по всему некий баг.
Надеялся, что это из-за не самого свежего 5.3 TL8

[Alex]

Меня тоже очень волнует эта тема:(
Поясните плз

Диск работает, iowait до 20% в принципе нормально

Я так понимаю если используется aio (а для oracle это скорее всего так) то iowait вообще не должно быть?

У меня периодически бывает на разделах 100% busy, лечится перезагрузкой

Было аналогично.
Только что патчили AIX 6.1 до SP6 поддержка нам обещала, что наша проблема исправлена.

[andrewk]

Я так понимаю если используется aio (а для oracle это скорее всего так) то iowait вообще не должно быть?

почему не должно быть? разница между синхронным и асинхронным I/O в принципе очень проста:

синхронное I/O:
1. приложение вызывает сисколл write()
2. ядро определяет на какое устройство будет осуществляться запись и передает управлению драйверу
3. драйвер пишет данные на устройство и возвращает код ошибки ядру
4. ядро возвращает код ошибки приложению
5. приложение работает дальше

асинхронное I/O
1. приложение вызывает сисколл write()
2. ядро возвращает управление приложению
3. приложение может работать дальше
4. ядро определяет на какое устройство будет осуществляться запись и передает управлению драйверу
5. драйвер пишет данные на устройство и возвращает код ошибки ядру
6. приложение должно само запрашивать отдельно код ошибки, чтобы выяснить была ли запись удачной

это грубая схема, не претендующая на абсолютную истину (в действительности все намного сложнее). Но смысл в том, что в любом случае драйвер будет писать данные на диск, а соответственно в любом случае диск будет занят – что с синхронным I/O, что с асинхронным.

[Alex]

Диск будет занят это понятно.

Но iowait это время в течении которого процесс ждет окончания I/O
А если у нас aio то процесс продолжает работать и не ждет ничего, откуда iowait ?
Или это будет время которое драйвер ждет?

[andrewk]

не процесс, а процессор.

% iowait
Shows the percentage of time that the CPU or CPUs were idle during which the system had an outstanding disk I/O request.

[Автор]

Сообщения