Странная статистика загрузки CPU

Главная Форумы POWER Systems AIX/Hardware Странная статистика загрузки CPU

Просмотр 28 веток ответов
  • Автор
    Сообщения
    • #13069
      Viacheslav Zabelin
      Участник

      cpu_load

      HW: p750 (Power7)

      LPAR profile (CPU):

      erpdb_cpu_profile

      OS: AIX 5.3

      Утилизация процессоров sys% 15-25% даже если ничего не запущено.
      С чем может быть связана подобная загрузка?

    • #13070
      Sever
      Участник

      Зачем число виртуальных процессоров назначено в два раза больше, чем выделено реальных?
      В таком режиме 50% их (виртуальных) всегда зафолжено…
      Уравняйте число виртуальных и выделеных по капасити и будет вам нормальная статистика…

    • #13072
      Viacheslav Zabelin
      Участник

      Пробовал. Такая же ситуация была.
      На выходных, думаю, будет возможность изменить настройки, проделаю еще раз.

    • #13073
      Sever
      Участник

      Все виртуальные процессоры, число которых больше реального числа физических, просто “висят в воздухе” и ничего полезного не делают. Система тратит впустую силы на их обслуживание. Это хорошо видно на вашей картинке. 16 последних столбиков – абсолютно вредная паразитная нагрузка.

    • #13089
      Viacheslav Zabelin
      Участник

      Изменил настройки.
      Теперь количество виртуальных процессоров соответствует количеству физических:

      erp-new_cpu_load_2_2011-09-09

      А “паразитаная” нагрузка осталась.

      erp-new_cpu_load_1

      Это может быть как-то связано с использованием Shared Processor pool?

    • #13090
      Viacheslav Zabelin
      Участник

      –Текст удален–

    • #13091
      andrewk
      Участник

      lparstat 2 100

    • #13092
      Viacheslav Zabelin
      Участник

      Это не весь вывод. Дальше все выглядит примерно также.

      $ lparstat 2 100

      System configuration: type=Shared mode=Uncapped smt=On lcpu=12 mem=32768 psize=16 ent=6.00

      %user %sys %wait %idle physc %entc lbusy vcsw phint
      —– —– —— —— —– —– —— —– —–
      0.5 1.2 2.4 96.0 0.14 2.3 1.1 2731 9
      0.4 0.9 3.0 95.6 0.11 1.9 1.2 2519 7
      0.4 0.8 2.9 95.9 0.10 1.7 0.8 2280 9
      0.3 0.7 3.0 96.0 0.08 1.4 0.7 2197 10
      0.2 0.8 3.0 96.0 0.08 1.4 0.5 2195 9
      0.3 0.8 2.9 96.0 0.09 1.5 0.7 2221 7
      0.3 0.7 2.8 96.2 0.08 1.4 0.8 2104 9
      0.3 0.8 2.9 96.0 0.09 1.5 0.8 2221 8
      0.3 0.8 2.3 96.6 0.09 1.5 0.9 2170 9
      0.8 1.0 3.1 95.2 0.14 2.3 1.3 2217 12
      0.3 0.6 2.4 96.8 0.07 1.2 0.5 2033 6
      0.2 0.5 2.9 96.3 0.07 1.1 0.6 2022 3
      0.4 0.9 2.5 96.2 0.11 1.9 1.0 2432 11
      0.4 1.0 3.2 95.4 0.12 2.0 1.0 2747 13
      0.6 0.9 3.0 95.4 0.13 2.1 1.1 2474 12
      0.3 0.9 3.1 95.7 0.10 1.7 1.3 2356 11
      0.3 0.9 3.4 95.5 0.10 1.6 0.6 2276 9
      0.3 0.9 3.4 95.4 0.10 1.7 0.6 2448 10
      0.4 1.0 3.3 95.3 0.12 2.0 1.0 2486 11
      0.5 0.9 2.9 95.8 0.11 1.8 0.8 2417 14
      0.3 0.8 2.9 96.0 0.09 1.5 0.6 2248 14
      %user %sys %wait %idle physc %entc lbusy vcsw phint
      —– —– —— —— —– —– —— —– —–
      0.3 0.8 3.0 95.9 0.09 1.5 0.8 2216 11
      0.7 1.0 2.8 95.6 0.13 2.2 1.2 2231 11
      2.8 1.8 2.5 93.0 0.34 5.7 3.4 3194 34
      2.9 1.8 0.8 94.6 0.35 5.9 3.2 3062 29
      1.6 2.6 0.0 95.8 0.32 5.3 2.5 1981 31
      0.9 1.5 0.0 97.6 0.19 3.1 1.6 2279 20
      0.7 1.1 0.0 98.2 0.14 2.4 1.1 2349 17
      0.6 1.0 0.0 98.4 0.13 2.2 1.1 2274 14
      0.7 1.1 0.0 98.2 0.14 2.4 1.2 1995 16
      0.6 1.2 0.0 98.2 0.14 2.4 1.5 1996 14
      1.4 2.4 0.0 96.2 0.29 4.9 2.3 1868 25
      0.3 0.6 0.0 99.0 0.08 1.4 0.8 2022 10
      1.6 2.6 0.0 95.9 0.31 5.2 2.7 1783 35
      1.5 2.5 0.0 96.0 0.30 5.1 2.8 1892 24
      0.4 0.8 0.0 98.8 0.10 1.7 0.8 2224 8
      0.5 0.8 0.0 98.7 0.10 1.7 1.2 2310 11
      0.5 0.8 0.0 98.7 0.11 1.8 1.2 2295 11
      0.4 0.8 0.0 98.8 0.10 1.7 0.9 2358 13
      0.5 0.8 0.0 98.7 0.10 1.7 1.2 2350 10
      0.4 0.8 0.0 98.8 0.10 1.7 0.8 2345 7
      1.5 1.1 0.0 97.4 0.20 3.3 1.6 2666 20

    • #13094
      Sever
      Участник

      Изменил настройки.
      Теперь количество виртуальных процессоров соответствует количеству физических:

      Это может быть как-то связано с использованием Shared Processor pool?

      Может. 5 ядер из 6 зафолжено. Имеет смысл посмотреть на настройки параметры работы других партиций на этой системе. Кто то явно конкурирует с текущей партицией.

    • #13095
      andrewk
      Участник

      из lparstat следует, что система не загружена. Ваша “паразитная” нагрузка, скорее всего, – vcsw (Virtual Context Switch), и она в пределах 1% – что нормально. иногда увеличивается количество phint – видимо “просыпается” какой-то другой LPAR на этой машине и начинает искать, у кого бы отобрать ресурсы 🙂 но тоже не критично.

      выводы, которые у меня напрашиваются –
      1) пустая система, которой не нужно столько процессоров – надо сократить количество процессоров (и физических, и виртуальных), возможно выключить насовсем SMT. если нагрузка в системе дается только от случая к случаю, то перенастроить соответственно LPAR.
      2) проблема, простите, в голове администратора – ничего сверхъестественного в системе не происходит

    • #13096
      Sever
      Участник

      В Lparstat процессорные параметры партиции phisc и %entc не соответствуют ожидаемым значениям.
      phisc дожна быть равна 6.00 для партиции на 6 ядрах, а %entc должна быть в районе 100процентов. Сейчас процентный расход ресурсов (затрачиваемые от имеющихся) расчитывается не от полной 100процентной емкости партиции, а от этих мелких значений. В итоге – на графиках фейковые показатели в десятки процентов…

    • #13097
      Viacheslav Zabelin
      Участник

      Если это действительно так, тогда это все обьясняет.

    • #13098
      andrewk
      Участник

      sever,

      phisc – это реально используемые физические процессора (ядра). Т.е. если LPAR’у отведено 6 процессоров (100% entc), но система используется на 10% от проектной мощности (entc = 10%), то phisc будет составлять 0.6. lparstat рассказывает все верно, а что там рисуется – хз 🙂

    • #13099
      Sever
      Участник

      Проверил на партиции c седьмым AIXом:

      В режиме один виртуальный на одном физическом phisc = 1.00, %entc = 100
      В режиме два виртуальных на двух физических phisc = 2.00, %entc = 100

      т.е. phisc – это текущая декларируемая физическая капасити.

    • #13100
      andrewk
      Участник

      man lparstat если мне не веришь 😉 LPAR’ов с 7м AIX’ом пока нет – это все с AIX 6 TL6, но в случае необходимости могу посмотреть и в man’e на AIX 7.

      physc
      Indicates the number of physical processors consumed.

      %entc
      Indicates the percentage of the entitled capacity consumed. Because the time base over which this data is computed can vary, the entitled capacity percentage can sometimes exceed 100%. This
      excess is noticeable only with small sampling intervals.

    • #13101
      andrewk
      Участник

      для чистоты совести, посмотрите плз еще mpstat -s

    • #13102
      Sever
      Участник

      man lparstat если мне не веришь 😉 LPAR’ов с 7м AIX’ом пока нет – это все с AIX 6 TL6, но в случае необходимости могу посмотреть и в man’e на AIX 7.

      physc
      Indicates the number of physical processors [B]consumed[/B].

      %entc
      Indicates the percentage of the entitled capacity [B]consumed[/B]. Because the time base over which this data is computed can vary, the entitled capacity percentage can sometimes exceed 100%. This
      excess is noticeable only with small sampling intervals.

      В man к 7.1 не изменилось ни строчки. Но различия в lparstat’e по этому парметру для 5.3 и 7.1 явно есть.

    • #13103
      andrewk
      Участник

      давай еще с твоим LPAR’ом разберемся, почему он на 100% загружен 😀

    • #13104
      Sever
      Участник

      🙂 Спасибо, у меня надобности нет.

    • #13109
      Дмитрий
      Участник

      Все виртуальные процессоры, число которых больше реального числа физических, просто “висят в воздухе” и ничего полезного не делают. Система тратит впустую силы на их обслуживание. Это хорошо видно на вашей картинке. 16 последних столбиков – абсолютно вредная паразитная нагрузка.

      [не в этом конкретном случае] не согласен.
      Часто бывает, что много “мелких” проуессоров лучше, чем мало “крупных”. Так многопоточная нагрузка лучше распараллеливается.
      Это и в теории, и на практике видно.
      А если LPAR uncapped, как, кстати, в рассматриваемом случае, то “лишние” виртуальные процессоры позволят забрать дополнительную процессорную мощность. Это легко проверить, поэкспериментировав с количестовм VP, одновременно нагружая систему в несколько потоков.

    • #13114
      Viacheslav Zabelin
      Участник

      2 andrewk:

      $ uptime
      10:51AM up 6 mins, 4 users, load average: 0.17, 0.22, 0.12
      $ lparstat

      System configuration: type=Shared mode=Uncapped smt=On lcpu=12 mem=32768 psize=16 ent=6.00

      %user %sys %wait %idle physc %entc lbusy vcsw phint
      —– —– —— —— —– —– —— —– —–
      0.0 0.0 0.5 99.5 0.00 0.0 0.7 134401 69
      $ mpstat -s

      System configuration: lcpu=12 ent=6.0 mode=Uncapped

      Proc0 Proc2 Proc4 Proc6 Proc8 Proc10
      0.00% 0.00% 0.00% 0.00% 0.00% 0.00%
      cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 cpu8 cpu9 cpu10 cpu11
      0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00% 0.00%

      Система пока не нагружена показать особенно нечего.

    • #13116
      Дмитрий
      Участник

      [quote quote="sever" post=12368]Все виртуальные процессоры, число которых больше реального числа физических, просто “висят в воздухе” и ничего полезного не делают. Система тратит впустую силы на их обслуживание. Это хорошо видно на вашей картинке. 16 последних столбиков – абсолютно вредная паразитная нагрузка.

      [не в этом конкретном случае] не согласен.
      Часто бывает, что много “мелких” процессоров лучше, чем мало “крупных”. Так многопоточная нагрузка лучше распараллеливается.
      Это и в теории, и на практике видно.
      А если LPAR uncapped, как, кстати, в рассматриваемом случае, то “лишние” виртуальные процессоры позволят забрать дополнительную процессорную мощность. Это легко проверить, поэкспериментировав с количестовм VP, одновременно нагружая систему в несколько потоков.[/quote]

    • #13117
      Дмитрий
      Участник

      Странный косяк… мой ответ пропадает…
      Вот он:

      (не в этом конкретном случае) не согласен.
      Часто бывает, что много “мелких” процессоров лучше, чем мало “крупных”. Так многопоточная нагрузка лучше распараллеливается.
      Это и в теории, и на практике видно.
      А если LPAR uncapped, как, кстати, в рассматриваемом случае, то “лишние” виртуальные процессоры позволят забрать дополнительную процессорную мощность. Это легко проверить, поэкспериментировав с количестовм VP, одновременно нагружая систему в несколько потоков

    • #13118
      Viacheslav Zabelin
      Участник

      На сколько я понимаю, Power7 наилучшую производительность показывает при 4 потоках на ядро. Но для этого aix должен уметь это делать. У меня 5.3 (умеет только 2 потока).
      Именно исходя из этих соображений изначально делал:

      Assigned Processor units: 6.00
      Assigned Virtual processors: 12.0
      Processor compatibility mode: Power7

    • #13120
      andrewk
      Участник

      (не в этом конкретном случае) не согласен.
      Часто бывает, что много “мелких” процессоров лучше, чем мало “крупных”. Так многопоточная нагрузка лучше распараллеливается.
      Это и в теории, и на практике видно.
      А если LPAR uncapped, как, кстати, в рассматриваемом случае, то “лишние” виртуальные процессоры позволят забрать дополнительную процессорную мощность. Это легко проверить, поэкспериментировав с количестовм VP, одновременно нагружая систему в несколько потоков

      это все правильно и замечательно, но: должна быть распараллеливаемая нагрузка. т.е. приложение должно уметь работать на десятке процессоров. Напомни мне плз, на скольких процессорах у Оракла будет выполняться одна stored процедура? 😉 Ну а если брать данную конкретную ситуацию – то там вообще нет нагрузки и даже одного VP будет много.

    • #13121
      andrewk
      Участник

      На сколько я понимаю, Power7 наилучшую производительность показывает при 4 потоках на ядро. Но для этого aix должен уметь это делать. У меня 5.3 (умеет только 2 потока).

      это не всегда так. очень сильно зависит от приложения. дибильный пример – делал сайзинг для syslog-сервера. Сам syslogd однотредовое приложение – ему можно включать и SMT2, и SMT4, толку не будет никакого. Но поскольку кроме syslogd на сервере работают еще всякие мелкие сервисы, то при включенном SMT2 были получены самые лучшие показатели производительности, а вот с SMT4 лучше не стало, даже как ни странно стало хуже. Да, все это было на 9119-MMB, в процессорах и памяти, которые потенциально можно было бы выделить LPAR’у, ограничений не было.

    • #13150
      uxTuaHgp
      Участник

      На сколько я понимаю, Power7 наилучшую производительность показывает при 4 потоках на ядро. Но для этого aix должен уметь это делать. У меня 5.3 (умеет только 2 потока).
      Именно исходя из этих соображений изначально делал:

      Assigned Processor units: 6.00
      Assigned Virtual processors: 12.0
      Processor compatibility mode: Power7

      Вообще неверное понимание темы.
      Виртуальных нужно ставить столько, сколько ты хочешь чтобы по максимуму выжирала партиция физических процессоров.
      Треды тут ни при чем.
      Кстати
      oslevel -s

    • #13167
      Viacheslav Zabelin
      Участник

      $ oslevel -s
      5300-12-01-1016

    • #13841
      boombox
      Участник

      [quote quote="slavon" post=12411]На сколько я понимаю, Power7 наилучшую производительность показывает при 4 потоках на ядро. Но для этого aix должен уметь это делать. У меня 5.3 (умеет только 2 потока).
      Именно исходя из этих соображений изначально делал:

      Assigned Processor units: 6.00
      Assigned Virtual processors: 12.0
      Processor compatibility mode: Power7

      Вообще неверное понимание темы.
      Виртуальных нужно ставить столько, сколько ты хочешь чтобы по максимуму выжирала партиция физических процессоров.
      Треды тут ни при чем.
      Кстати
      oslevel -s[/quote]

      Для Uncapped. Для Uncapped. B)

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