Утилизация процессора что это
Перейти к содержимому

Утилизация процессора что это

  • автор:

Метрика загруженности процессора (CPU utiliztion) — это не то что вы думаете

Всем привет. Предлагаю вашему вниманию свой перевод поста “CPU Utilization is Wrong” из блога Брендана Грегга. Метрика загруженности процессора (CPU utiliztion), которую все мы привыкли использовать, обычно понимается неправильно. Что такое загруженность процессора? То насколько процессор сейчас занят работой? Нет, это не так, и да, я говорю о метрике %CPU , которая используется всегда и везде, в каждой утилите мониторинга производительности, например в top(1) . Как вы думаете, что значит нагрузка на процессор 90% на картинке ниже? Вот что это значит на самом деле: Stalled, то есть “приостановлено” значит, что в данный момент процессор не обрабатывает инструкции, обычно это означает, что он ожидает завершения операций ввода/вывода связанных с памятью (здесь и далее речь о RAM, а не дисковом вводе/выводе). Соотношение между “занято” и “приостановлено” (busy/stalled), которое я привел выше, это то что я обычно вижу в продакшене. Вероятно, что ваш процессор тоже большую часть времени находится в stalled состоянии, но вы об этом и не догадываетесь. Что это значит для вас? Понимание того насколько много ваш процессор находится в приостановленном состоянии может помочь вам понять куда направить усилия по оптимизации производительности приложения: на ускорение кода или уменьшение числа операций ввода/вывода связанных с памятью. Всем кто заинтересован в оптимизации нагрузки на процессор, в особенности в облаках с настроенным автомасштабированием на основе нагрузки на CPU, будет полезно знать насколько долго процессор находится в приостановленном состоянии.

Что такое нагрузка на процессор на самом деле?

Метрика, которую мы называем нагрузкой на процессор (CPU utilization) на самом деле это “не-idle время”, то есть время, которое процессор не выполняет idle-тред. Ядро вашей операционной системы (какую бы ОС вы не использовали) обычно следит за этим во время переключения контекста. Если не-idle тред запустился, а затем спустя 100 милисекунд остановился, то ядро посчитает, что процессор был использован в течение всего этого времени. Эта метрика так же стара как и системы совместного использования времени (time sharing systems). В бортовом компьютере лунного модуля Apollo (это пионер среди систем совместного использования времени) idle-тред назывался “DUMMY JOB” и инженеры мониторили циклы выполняющие его в сравнении с реальными задачами, это было важной метрикой измерения нагрузки. (Я писал об этом ранее). Что же с этой метрикой не так? В наши дни процессоры работают значительно быстрее памяти, поэтому время ожидания памяти доминирует в метрике “нагрузка на процессор”. Когда вы видите большие значение %CPU в top(1) , вы, должно быть, думаете, что процессор является бутылочным горлышком, когда на самом деле проблема в DRAM. Со временем все становится только хуже. Долгое время производители процессоров увеличивали тактовые частоты своих процессоров быстрее чем производители памяти уменьшали задержки доступа к памяти (CPU DRAM gap). Примерно в 2005 году процессоры достигли частот в 3 GHz и с тех пор мощность процессоров растет не за счет увеличения тактовой частоты, а за счет большего числа ядер, гипертрединга и многопроцессорных конфигураций. Все это предъявляет еще больше требований к памяти. Производители процессоров пытались снизить задержки связанные с памятью за счет больших по размеру и более умных CPU-кешей, более быстрых шин и соединений. Но проблема со stalled-состоянием все еще не решена.

Как понять, что процессор на самом деле делает

Сделать это можно используя Performance Monitoring Counters (PMC-счетчики): хардверные счетчики, которые могут быть прочитаны с помощью Linux pref (пакет linux-tools-generic в Линуксе) и других утилит. Для примера понаблюдаем за всей системой в течение 10 секунд:

# perf stat -a -- sleep 10 Performance counter stats for 'system wide': 641398.723351 task-clock (msec) # 64.116 CPUs utilized (100.00%) 379,651 context-switches # 0.592 K/sec (100.00%) 51,546 cpu-migrations # 0.080 K/sec (100.00%) 13,423,039 page-faults # 0.021 M/sec 1,433,972,173,374 cycles # 2.236 GHz (75.02%) stalled-cycles-frontend stalled-cycles-backend 1,118,336,816,068 instructions # 0.78 insns per cycle (75.01%) 249,644,142,804 branches # 389.218 M/sec (75.01%) 7,791,449,769 branch-misses # 3.12% of all branches (75.01%) 10.003794539 seconds time elapsed 

Ключевая метрика здесь instructions per cycle (insns per cycle: IPC, число инструкций за один цикл), которая показывает сколько в среднем инструкций было выполнено за каждый такт. Чем больше, тем лучше. В примере выше значение 0.78 кажется очень неплохим (нагрузка 78%?) до тех пор пока вы не узнаете, что максимальная скорость процессора это IPC 4.0. Такие процессоры называют 4-wide, это название пошло от особенностей пути извлечения/декодирования инструкций в процессоре (подробнее об этом в Википедии). Это означает, что процессор может выполнить 4 операции за каждый такт, поэтому значение 0.78 для 4-wide системы означает, что процессор работает на 19,5% от своих возможностей. Новый процессор Skylake от Intel — это 5-wide процессор. Существуют сотни PMC-счетчиков, которые позволяют детальнее разобраться с производительностью системы, например, посчитать число приостановленных циклов по типам.

В облаках

Если вы работаете в виртуальном окружении, то вероятно у вас нет доступа к PMC-счетчикам, это зависит от поддержки этой фичи гипервизором. Я недавно писал о том, что PMC-счетчики теперь доступны в AWS EC2 в виртуальных машинах базирующихся на Xen.

Как интерпретировать и что делать

Если ваш IPC < 1.0 , то вероятнее всего, процессор приостановлен из-за медленной памяти, поэтому нужно оптимизировать софт так, чтобы он требовал меньше операций с памятью, совершенствовать кеширование в процессоре и локальность памяти, особенно в NUMA системах. Оптимизация железа в таком случае подразумевает использование процессоров с большим объемом кешей, более быстрой памятью, шинами и соединениями. Если ваш IPC > 1.0 , то вероятно, вы ограничены числом инструкций, которые может выполнять процессор. Попробуйте найти способ уменьшить число выполняемых инструкций: уменьшить число ненужной работы, кешировать операции и т.п. CPU flame графы — отличная утилита для этих целей. С точки зрения тюнинга железа, попробуйте использовать процессор с большей тактовой частотой и большим числом ядер и гипертредов. Для моих правил выше я выбрал значение IPC 1.0, почему именно его? Я пришел к нему из своего опыта работы с PMC-счетчиками. Вы можете выбрать для себя другое значение. Сделайте два тестовых приложения, одно упирающееся по производительности в процессор, другое — в память. Посчитайте IPC для них и возьмите среднее значение.

Что инструменты мониторинга производительности должны сообщать вам?

Каждая такая утилита должны показывать IPC вместе с нагрузкой на процессор. Или разделять нагрузку на процессор на instruction-retired и циклы stalled циклы, то есть, %INS и %STL . Кроме утилиты top(1) для Линукса есть утилита tiptop(1) , которая показывает IPC для каждого процесса:

tiptop - [root] Tasks: 96 total, 3 displayed screen 0: default PID [ %CPU] %SYS P Mcycle Minstr IPC %MISS %BMIS %BUS COMMAND 3897 35.3 28.5 4 274.06 178.23 0.65 0.06 0.00 0.0 java 1319+ 5.5 2.6 6 87.32 125.55 1.44 0.34 0.26 0.0 nm-applet 900 0.9 0.0 6 25.91 55.55 2.14 0.12 0.21 0.0 dbus-daemo 

Другие причины почему CPU utilization вводит в заблуждение

  • изменение температуры может влиять на приостановленность процессора,
  • турбобуст может менять тактовую частоту процессора,
  • ядро варьирует частоту процессора с определенным шагом,
  • проблема с усреднением: 80% нагрузки в течение минуты скроет кратковременный всплеск до 100%,
  • спинлоки: процессор нагружен, имеет высокий IPC, но приложение ничего не делает.

Заключение

Нагрузка на процессор (CPU utilization) это обычно неправильно интерпретируемая метрика, так как она включает циклы, потраченные на ожидание ответа от основной памяти, которые могут доминировать в современных нагрузках. Вы можете понять что на самом деле стоит за %CPU используя дополнительные метрики, включая число инструкций за цикл (IPC). Если IPC < 1.0 , то вероятно вы упираетесь в память, если IPC >1.0 , то в скорость процессора. Я писал про IPC в своем предыдущем посте, в том числе написал и о использовании PMC-счетчиках, необходимых для измерения IPC.

Инструменты мониторинга производительности, которые показывают %CPU должны показывать PMC-счетчики, чтобы не вводить пользователей в заблуждение. Например, они могут показывать %CPU с IPC и/или число instruction-retired и stalled циклов. Вооруженные этими метриками разработчики и админы могут решить как правильнее тюнинговать их приложения и системы.

Утилизация процессора что это

(19) а попробуй объясни как это выяснить сколько «использования ЦП» занимает подключение к примеру усб-устройства ?

Я утилизировал Целерон-366 путем отдавания его в пользование ребенку. Он его таскал в портфеле и показывал знакомым пацанам. Щас валяется у него на столе и используется почти в качестве брелока-игрушки. :))

з.ы. вот думаю — может ему отдать пару материнок от 286 компа? :)))

+(22) или собрать 286-ю и пускай Диггера с ПакМаном погоняет?? :))
(22) не надо, не травмируй ребенка

(21) Без проблем. Делаешь ps -e, находишь номер процесса, который занимается обработкой твоего usb устройства. Затем заходишь в /proc/номер процесса/ там есть файлик, в котором написано сколько «тиков» процессора использовал данный процесс. Делаешь выборку за несколько секунд и делишь колическтво потраченных «тиков» на общее число. Общее число лежит в фале в каталоге /proc/. Имя файла я точно не помню, но гугл в помощь.

(23) Хорошая идея. Поставь туда паскаль и дай пару занимательных книжек по программингу. Пусть побалуется, когда игрушки надоедят.

(26) Я уже давно его к этому делу подталкиваю. Он даже в VB6 кое-что «творил», но. Игрушки победили :((( Их тварей клепают с поражающей скоростью :(((

(27) VB — отстой. Поставь ему линукс, пусть с ним повозится, тоже очень развивает. Ну и на программирование может плавно перескочит )

(28) КУЯСЕ. Я его сам не знаю! Так что еще вопрос — куму развиваться в первую очередь придется :)))

з.ы. А мне оно точно не надь :)) Неохота. :))

(29) Да ладно тебе, он по большей части дружественный. Просто есть пара вещей, из-за которых для детей он лучше чем винда:
— Чтоб поставить игрушку, придется поразбираться )
— Чтоб настроить что-то нестандартное, придется хорошо поразбираться.
А работа мозга — штука полезная 😉

(30) Не, не будет разбираться. В 12 лет не о том они думают. По крайней мере моему пока рановато. Да и живет с «бывшей» — я в другом месте.

% CPU Utilization

Учитывая, что на большинстве платформ есть отдельный счётчик ЦПУ простоя (см. Связанные метрики), советуем использовать следующую формулу для расчета потребления ЦПУ: CPU Consumption = 100 — Idle CPU (%)

Расследование стоит начинать со счётчика Утилизации ЦПУ пользовательского режима, чтобы определить, на что расходуется ресурс ЦПУ: на процессы пользователя или ядра

  • CPU Utilization\%idle (% утилизации ЦПУ во время простоя)
  • CPU Utilization\%usr (% утилизации ЦПУ в пользовательском режиме)
  • CPU Utilization\%sys (% утилизации ЦПУ в системном режиме) (Solaris)
  • Processor\Idle
  • Processor\Kernel (Linux)
  • Processor\%idle
  • Processor\%usr
  • Processor\%sys (AIX)

Примечание: Высокий процент утилизации процессоров на машине не всегда означает наличие проблемы, которую нужно решать. Однако стоит разобраться в причинах, если время простоя ЦПУ ниже 20%, а его падение ниже 10% может свидетельствовать об ошибке.

CPU Load: когда начинать волноваться?

Данная заметка является переводом статьи из блога компании Scout. В статье дается простое и наглядное объяснение такого понятия, как load average . Статья ориентирована на начинающих Linux-администраторов, но, возможно, будет полезна и более опытным админам. Заинтересовавшимся добро пожаловать под кат.

Вероятно, Вы уже знакомы с понятием load average . Load average — это три числа, отображаемые при выполнении команд top и uptime . Выглядят они примерно так:

load average: 0,35, 0,32, 0,41 

Большинство интуитивно понимают, что эти три числа обозначают средние значения загрузки процессора на прогрессивно увеличивающихся временных промежутках (одна, пять и пятнадцать минут) и чем меньше их значения — тем лучше. Большие числа свидетельствуют о слишком большой нагрузке на сервер. Но какие значения считать предельными? Какие значения являются «плохими», а какие — «хорошими»? Когда Вам следует просто волноваться о занчениях средней загрузки, а когда следует бросать другие дела и решать проблему так быстро, как это возможно?
Для начала, давайте разберемся, что же означает load average . Рассмотрим простейший случай: предположим, что у нас в наличии один сервер с одноядерным процессором.

Аналогия транспортного потока

Одноядерный процессор похож на дорогу с одной полосой движения. Представьте себе, что Вы управяете движением машин по мосту. Иногда, Ваш мост загружен настолько сильно, что машинам приходится ждать в очереди чтобы проехать по нему. Вы хотите дать людям понять, как долго им придется ждать чтобы перебраться на другую сторону реки. Хорошим способом сделать это будет показать как много машин ждут в очереди в конкретный момент времени. Если машин в очереди нет, подъезжающие водители будут знать, что они сразу смогут проехать по мосту. В противном случае, они будут понимать, что придется ждать своей очереди.
Итак, Управляющий Мостом, какую систему обозначений Вы будете использовать? Как насчет такой:

  • 0.00 означает, что на мосту нет ни одной машины. Фактически, значения от 0.00 до 1.00 означают отсутствие очереди. Подъезжающая машина может воспользоваться мостом без ожидания;
  • 1.00 означает, что на мосту находится как раз столько автомобилей, сколько он может вместить. Все еще идет хорошо, но, в случае увеличения потока машин, возможны проблемы;
  • Значения, превышающие 1.00 означают наличие очереди на въезде. Насколько большой? Например, значение 2.00 показывает, что в очереди стоит столько же автомобилей, сколько движется по мосту. 3.00 означает, что мост полностью занят и в очереди ожидает в два раза больше машин, чем он может вместить. И так далее.

imageload average = 1.00
imageload average = 0.50
imageload average = 1.70
Вот базовое значение загрузки процессора. «Машины» обрабатываются с использованием промежутков процессорного времени («пересекают мост»), либо ставятся в очередь. В Unix это называется длина очереди выполнения: количество всех процессов, выполняемых в данный момент времени, плюс количество процессов, ожидающих в очереди.
Вам, как управляющему мостом, хотелось бы, чтобы машины-процессы никогда не ждали в очереди. Таким образом, предпочтительно, чтобы загрузки процессора была всегда ниже 1.00. Периодически возможны всплески трафика, когда загрузка будет превышать 1.00, но если она постоянно превышает данное значение — это повод начать волноваться.

Так Вы говорите, 1.00 — идеальное значание load average?
  • Практическое правило «Требуется присмотр»: 0.70. Если среднее значение загрузки постоянно превышает 0.70, следует выяснить причину такого поведения системы во избежании проблем в будущем;
  • Практическое правило «Почини это немедленно!»: 1.00. Если средняя загрузка системы превышает 1.00, необходимо срочно найти причину и устранить ее. В противном случае, Вы рискуете быть разбуженным посреди ночи и это точно не будет весело;
  • Практическое правило «Щас же 3 ночи. ШОЗАНАХ. »: 5.00. Если среднее значение загрузки процессора превышает 5.00, у Вас серьезные проблемы. Сервер может подвисать или работать очень медленно. Скорее всего, это произойдет в худший из возможных моментов. Например, посреди ночи или когда Вы выступаете с докладом на конференции.
Что насчет многопроцессорных систем? Мой сервер показывает загрузку 3.00 и все ОК!

У Вас четырехпроцессорная система? Все в порядке, если load average равен 3.00.
В мультипроцессорных системах загрузка вычисляется относительно количества доступных процессорных ядер. 100% загрузка обозначается числом 1.00 для одноядерной машины, числом 2.00 для двуядерной, 4.00 для четырехъядерной и т.д.
Если вернуться к нашей аналогии с мостом, 1.00 означает «одну полностью загруженную полосу движения». Если на мосту всего одна полоса, 1.00 означает, что мост загружен на 100%, если же в наличии две полосы, он загружен всего на 50%.
То же самое с процессорами. 1.00 означает 100% загрузки одноядерного процессора. 2.00 — 100% загрузки двуядерного и т.д.

Многоядерность vs. многопроцессорность
  • «Количество ядер = максимальная загрузка». На многоядерной системе, загрузка не должна превышать количества доступных ядер;
  • «Ядра — они и в Африке ядра». То, как ядра распределены по процессорам — неважно. Два четырехъядерных = четыре двуядерных = восем одноядерных процессоров. Имеет значение лишь общее число ядер.
Сведем все вместе

Давайте посмотрим на средние значения загрузки с помощью команды uptime :

~$ uptime 09:14:44 up 1:20, 5 users, load average: 0,35, 0,32, 0,41 

Здесь представлены показатели для системы с четырехъядерным процессором и мы видим, что имеется большой запас по нагрузке. Я даже не буду задумываться о ней, пока load average не превысит 3.70.

Какое среднее значение мне следует контролировать? Для одной, пяти или 15 минут?

Для значений, о которых мы говорили раньше (1.00 — почини это немедленно и т.д.), следует рассматривать временные промежутки в пять и 15 минут. Если загрузка Вашей системы превышает 1.00 на интервале в одну минуту, все в порядке. Если же загрузка превышает 1.00 на пяти- или 15-минутном интервале, Вам следует начать принимать меры (конечно, Вам следует также принимать во внимание количество ядер в Вашей системе).

Количество ядер важно для правильно понимания load average. Как мне его узнать?

Команда cat /proc/cpuinfo выводит информацию обо всех процессорах в вашей системе. Чтобы узнать количество ядер, «скормите» ее вывод утилите grep :

~$ cat /proc/cpuinfo | grep 'cpu cores' cpu cores : 4 cpu cores : 4 cpu cores : 4 cpu cores : 4 
Примечания переводчика

Выше представлен перевод самой статьи. Также много интересной информации можно почерпнуть из комментариев к ней. Так, один из комментаторов говорит о том, что не для каждой системы важно иметь запас по производтельности и не допускать значения загрузки выше 0.70 — иногда нам нужно чтобы сервер работал «на всю катушку» и в таких случаях load average = 1.00 — то, что доктор прописал.

PS

Хабраюзер dukelion добавил в комментариях ценное замечание, что в некоторых сценариях, для достижения максимального КПД «железа», стоит держать значение load average несколько выше 1.00 в ущерб эффективности работы каждого отдельного процесса.

PPS

Хабраюзер enemo в комментариях добавил замечание о том, что высокий показатель load average может быть вызван большим количеством процессов, выполняющих в данный момент операции чтения/записи. То есть, load average > 1.00 на одноядерной машине не всегда говорит о том, что в Вашей системе отсутствует запас по загрузке процессора. Требуется более внимательное изучение причин такого показателя. Кстати, это хорошая тема для нового поста на Хабре 🙂

PPPS

Хабраюзер esvaf в комментариях интересуется, как интерпретировать значения load average в случае использования процессора с технологией HyperThreading. Однозначного ответа на данный момент я не нашел. В данной статье утверждается, что процессор, который имеет два виртуальных ядра при одном физическом, будет на 10-30% более производительным, чем простой одноядерный. Если принимать такое допущение за истину, считаю, при интерпретации load average стоит брать в расчет только количество физических ядер.

  • linux
  • перевод с английского

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *