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

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

Просмотр 8 веток ответов
  • Автор
    Сообщения
    • #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.

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