Главная › Форумы › POWER Systems › AIX/Hardware › Постоянно tm_act 100% для одного диска в AIX 6.1
- В этой теме 8 ответов, 5 участников, последнее обновление 9 лет, 1 месяц назад сделано
andrewk.
-
АвторСообщения
-
-
18.11.2011 в 08:22 #14016
Дмитрий
УчастникВсем привет. Возникла небольшая проблема и некое непонимание.
Имеем 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 2656Paths: % 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 632Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk11 100.1 6444.3 805.5 6440 0Paths: % 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 0Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk11 99.8 32603.9 4004.7 30760 1920Paths: % 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 440Disks: % tm_act Kbps tps Kb_read Kb_wrtn
hdisk11 99.7 34548.4 4318.0 34640 12Paths: % 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.00kthr 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 28000Transfer Size: <= 512 <= 4k <= 16K <= 64K > 64K
231 501 32073969 2083518 5185422
[/code]
К сожалению, информации о конфигурации СХД пока нет, но могу постараться достать. Знающие люди советуют раздобыть showfbvol -metrics и showextpool -metrics для LUN и пула в котором этот LUN. Может быть что-то еще? -
18.11.2011 в 08:41 #14017
andrewk
Участника почему Вас это беспокоит? 🙂 Диск работает, iowait до 20% в принципе нормально. Пользователи пожаловались, что приложение стало тормозить? Поищите, кто так активно пишет на этот диск (filemon), возможно стоит из одного диска сделать два, или перенести какую-то нагрузку на другой, менее загруженный диск
-
18.11.2011 в 09:57 #14018
Дмитрий
УчастникНачалось все с того, что прикладники получали письмо от нотификатора Оракла следующего вида:
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%. Видимо, я что-то не понимаю. Собственно, захотелось понять и разобраться. -
21.11.2011 в 10:11 #14023
Ivan
Участник%tm_act – это % времени которое том был активен.
Если большие очереди на томах и адаптерах, значение в колонке b вывода vmstat большие (значительно больше) устройств ввода вывода (путей), высокие значения wa (однако, в некоторых случаях по высокому значению wa нельзя говорить о проблемах в IO), то можно говорить что где-то проблемы.
imho, busy ~100% не говорит о полной загрузке дисковой подсистемы.
В приложенном выводе проблем, imho, нет (смешные нагрузки для такого массива). -
27.11.2011 в 11:16 #14081
Александр Фролушкин
УчастникУ меня периодически бывает на разделах 100% busy, лечится перезагрузкой. Судя по всему некий баг.
Надеялся, что это из-за не самого свежего 5.3 TL8 -
28.11.2011 в 18:20 #14089
Alex
УчастникМеня тоже очень волнует эта тема:(
Поясните плзДиск работает, iowait до 20% в принципе нормально
Я так понимаю если используется aio (а для oracle это скорее всего так) то iowait вообще не должно быть?
У меня периодически бывает на разделах 100% busy, лечится перезагрузкой
Было аналогично.
Только что патчили AIX 6.1 до SP6 поддержка нам обещала, что наша проблема исправлена. -
28.11.2011 в 18:34 #14090
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, что с асинхронным.
-
28.11.2011 в 18:45 #14091
Alex
УчастникДиск будет занят это понятно.
Но iowait это время в течении которого процесс ждет окончания I/O
А если у нас aio то процесс продолжает работать и не ждет ничего, откуда iowait ?
Или это будет время которое драйвер ждет? -
28.11.2011 в 19:07 #14092
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.
-
-
АвторСообщения
- Для ответа в этой теме необходимо авторизоваться.