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


Главная Форумы POWER Systems AIX/Hardware Постоянно tm_act 100% для одного диска в AIX 6.1

В этой теме 8 ответов, 5 участников, последнее обновление  andrewk 6 года/лет назад.

  • Автор
    Сообщения
  • #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 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. Может быть что-то еще?

  • #14017

    andrewk
    Участник

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

  • #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%. Видимо, я что-то не понимаю. Собственно, захотелось понять и разобраться.

  • #14023

    Ivan
    Участник

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

  • #14081

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

  • #14089

    Alex
    Участник

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

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

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

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

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

  • #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, что с асинхронным.

  • #14091

    Alex
    Участник

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

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

  • #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.

Для ответа в этой теме необходимо авторизоваться.