Назад | Перейти на главную страницу

Что на самом деле означает метрика «Процесс / ЦП»?

Я использую отличный наверху для подробного анализа влияния нагрузочного теста, а различие между метрикой SystemLevel / CPU в верхнем (общесистемном) разделе и метрикой ProcessLevel / CPU в нижнем (для каждого процесса) разделе меня озадачило. Мне известны похожие вопросы, но я не нашел ни одного, который объяснял бы использование контекста, который я уже понимаю.

1. Это% доступной мощности или% используемой мощности?

Метрика ProcessLevel / CPU описана в справочная страница как «Процент занятости этого процесса, связанный с доступной мощностью для этого ресурса на системном уровне». Сравните это с:

ProcessLevel / DSK («Процент занятости этого процесса, связанный с общей нагрузкой, производимой всеми процессами (т. Е. Общим доступом к диску всеми процессами за последний интервал)»), и с
очевидный эквивалент «использования ЦП» («Доля задачи в затраченном времени ЦП с момента последнего обновления экрана, выраженная в процентах от общего времени ЦП»).

Оба они, кажется, относятся к проценту занятости, относящемуся к "... используемый вместимость ... ", что сильно отличается от" ... доступный емкость ... ". Предполагая, что описание справочной страницы верно ...

2. Что такое «доступная мощность»?

Если это действительно мониторинг «доступной мощности», что это значит? Иллюстрация ниже, с ProcessLevel / CPU на 97%, когда его CPU простаивает на 43%, кажется, показывает, что это не может быть тесно связано с максимумами SystemLevel / CPU. Может быть, это связано с временем ожидания диска или сети?

3. Как это может быть> 100%?

Это просто статистическая ошибка / ошибка выборки? Подлежит ли он тому же «100% = 1 макс. ЦП», что и% ЦП верхнего уровня? Если да, то как наш однопоточный узел pal может использовать> 100% в последнем примере ниже?

Иллюстративные образцы

В качестве иллюстрации (можно открыть дополнительные червячки node / xen / aws, в этом случае извините, но я все равно признателен за мудрость SF и буду рад задать другие вопросы) ...

Приложение узла, которое я тестирую (с отличным Vegeta) успешно обрабатывает конкретный тип запроса на загрузку на экземпляре AWS с 4 ЦП со скоростью 10 запросов / с. При этой нагрузке ProcessLevel / CPU узла составляет около 69%:

CPU sys: 73% | user: 155% | irq: 6% | idle: 143% | wait:    21% | steal: 1%
cpu sys: 18% | user:  36% | irq: 0% | idle:  43% | cpu002 w: 3% | steal: 0%

...                 blah                 ...           CPUNR    CPU    CMD
                                                           2    69%    node

(Я предполагаю, что cpu002 соответствует CPUNR = 2).

При загрузке 14 запросов / с, которую сервер не обрабатывает (таймауты 35%), ProcessLevel / CPU для узла увеличивается до 97%:

CPU sys: 59% | user: 142% | irq: 5% | idle: 170% | wait:    22% | steal: 1%
cpu sys: 14% | user:  40% | irq: 0% | idle:  42% | cpu003 w: 3% | steal: 0%

...                 blah                 ...           CPUNR    CPU    CMD
                                                           3    97%    node

Итак, если ProcessLevel / CPU означает% от доступный Ресурс ЦП, как узел может использовать 97% доступного ресурса ЦП, когда его ЦП простаивает на 43%? Или (с риском отклонения от темы), если ProcessLevel / CPU означает% от используемый Ресурс ЦП, почему эта метрика так близко соответствует максимальной нагрузке, когда есть много свободного ЦП, и он не ждет диска (максимальное значение сетевого адаптера ...)?

Последний образец, для вопроса> 100%, вот тот же самый ящик, действительно забитый на 16 запросов / с (ProcessLevel / CPU теперь до 111% и все запросы терпят неудачу):

CPU sys: 44% | user: 125% | irq: 4% | idle: 203% | wait:    24% | steal: 1%
cpu sys: 12% | user:  38% | irq: 4% | idle:  41% | cpu001 w: 5% | steal: 0%

...                 blah                 ...           CPUNR    CPU    CMD
                                                           1   111%    node

Ура!