Что такое утилизация цпу
% CPU Utilization
| Официальное название | CPU Utilization Counter |
| Тип счётчика | Интервальный (% занятости) |
| Описание | Усреднённая утилизация процессора за интервал времени. На каждом отрезке, на котором не выполняется Idle Thread, процессор считается занятым какой-то реальной нагрузкой. Этот счётчик – сумма показателей утилизации ЦПУ пользователем, системой и во время простоя (Idle + User + System utilization, названия могут отличаться на разных платформах) |
Расследование стоит начинать со счётчика Утилизации ЦПУ пользовательского режима, чтобы определить, на что расходуется ресурс ЦПУ: на процессы пользователя или ядра
Примечание: Высокий процент утилизации процессоров на машине не всегда означает наличие проблемы, которую нужно решать. Однако стоит разобраться в причинах, если время простоя ЦПУ ниже 20%, а его падение ниже 10% может свидетельствовать об ошибке.
Метрика загруженности процессора (CPU utiliztion) — это не то что вы думаете
Всем привет. Предлагаю вашему вниманию свой перевод поста «CPU Utilization is Wrong» из блога Брендана Грегга.
Как вы думаете, что значит нагрузка на процессор 90% на картинке ниже?
Вот что это значит на самом деле:
Stalled, то есть «приостановлено» значит, что в данный момент процессор не обрабатывает инструкции, обычно это означает, что он ожидает завершения операций ввода/вывода связанных с памятью (здесь и далее речь о RAM, а не дисковом вводе/выводе). Соотношение между «занято» и «приостановлено» (busy/stalled), которое я привел выше, это то что я обычно вижу в продакшене. Вероятно, что ваш процессор тоже большую часть времени находится в stalled состоянии, но вы об этом и не догадываетесь.
Что это значит для вас? Понимание того насколько много ваш процессор находится в приостановленном состоянии может помочь вам понять куда направить усилия по оптимизации производительности приложения: на ускорение кода или уменьшение числа операций ввода/вывода связанных с памятью. Всем кто заинтересован в оптимизации нагрузки на процессор, в особенности в облаках с настроенным автомасштабированием на основе нагрузки на CPU, будет полезно знать насколько долго процессор находится в приостановленном состоянии.
Что такое нагрузка на процессор на самом деле?
Метрика, которую мы называем нагрузкой на процессор (CPU utilization) на самом деле это «не-idle время», то есть время, которое процессор не выполняет idle-тред. Ядро вашей операционной системы (какую бы ОС вы не использовали) обычно следит за этим во время переключения контекста. Если не-idle тред запустился, а затем спустя 100 милисекунд остановился, то ядро посчитает, что процессор был использован в течение всего этого времени.
Эта метрика так же стара как и системы совместного использования времени (time sharing systems). В бортовом компьютере лунного модуля Apollo (это пионер среди систем совместного использования времени) idle-тред назывался «DUMMY JOB» и инженеры мониторили циклы выполняющие его в сравнении с реальными задачами, это было важной метрикой измерения нагрузки. (Я писал об этом ранее).
Что же с этой метрикой не так?
Со временем все становится только хуже. Долгое время производители процессоров увеличивали тактовые частоты своих процессоров быстрее чем производители памяти уменьшали задержки доступа к памяти (CPU DRAM gap). Примерно в 2005 году процессоры достигли частот в 3 GHz и с тех пор мощность процессоров растет не за счет увеличения тактовой частоты, а за счет большего числа ядер, гипертрединга и многопроцессорных конфигураций. Все это предъявляет еще больше требований к памяти. Производители процессоров пытались снизить задержки связанные с памятью за счет больших по размеру и более умных CPU-кешей, более быстрых шин и соединений. Но проблема со stalled-состоянием все еще не решена.
Как понять, что процессор на самом деле делает
Сделать это можно используя Performance Monitoring Counters (PMC-счетчики): хардверные счетчики, которые могут быть прочитаны с помощью Linux pref (пакет linux-tools-generic в Линуксе) и других утилит. Для примера понаблюдаем за всей системой в течение 10 секунд:
Ключевая метрика здесь instructions per cycle (insns per cycle: IPC, число инструкций за один цикл), которая показывает сколько в среднем инструкций было выполнено за каждый такт. Чем больше, тем лучше. В примере выше значение 0.78 кажется очень неплохим (нагрузка 78%?) до тех пор пока вы не узнаете, что максимальная скорость процессора это IPC 4.0. Такие процессоры называют 4-wide, это название пошло от особенностей пути извлечения/декодирования инструкций в процессоре (подробнее об этом в Википедии).
Существуют сотни PMC-счетчиков, которые позволяют детальнее разобраться с производительностью системы, например, посчитать число приостановленных циклов по типам.
В облаках
Если вы работаете в виртуальном окружении, то вероятно у вас нет доступа к PMC-счетчикам, это зависит от поддержки этой фичи гипервизором. Я недавно писал о том, что PMC-счетчики теперь доступны в AWS EC2 в виртуальных машинах базирующихся на Xen.
Как интерпретировать и что делать
Если ваш IPC 1.0, то вероятно, вы ограничены числом инструкций, которые может выполнять процессор. Попробуйте найти способ уменьшить число выполняемых инструкций: уменьшить число ненужной работы, кешировать операции и т.п. CPU flame графы — отличная утилита для этих целей. С точки зрения тюнинга железа, попробуйте использовать процессор с большей тактовой частотой и большим числом ядер и гипертредов.
Для моих правил выше я выбрал значение IPC 1.0, почему именно его? Я пришел к нему из своего опыта работы с PMC-счетчиками. Вы можете выбрать для себя другое значение. Сделайте два тестовых приложения, одно упирающееся по производительности в процессор, другое — в память. Посчитайте IPC для них и возьмите среднее значение.
Что инструменты мониторинга производительности должны сообщать вам?
Другие причины почему CPU utilization вводит в заблуждение
Проблема со stalled-циклами может быть не только в задержках связанных с памятью:
— изменение температуры может влиять на приостановленность процессора,
— турбобуст может менять тактовую частоту процессора,
— ядро варьирует частоту процессора с определенным шагом,
— проблема с усреднением: 80% нагрузки в течение минуты скроет кратковременный всплеск до 100%,
— спинлоки: процессор нагружен, имеет высокий IPC, но приложение ничего не делает.
Заключение
Нагрузка на процессор (CPU utilization) это обычно неправильно интерпретируемая метрика, так как она включает циклы, потраченные на ожидание ответа от основной памяти, которые могут доминировать в современных нагрузках. Вы можете понять что на самом деле стоит за %CPU используя дополнительные метрики, включая число инструкций за цикл (IPC). Если IPC 1.0, то в скорость процессора. Я писал про IPC в своем предыдущем посте, в том числе написал и о использовании PMC-счетчиках, необходимых для измерения IPC.
Инструменты мониторинга производительности, которые показывают %CPU должны показывать PMC-счетчики, чтобы не вводить пользователей в заблуждение. Например, они могут показывать %CPU с IPC и/или число instruction-retired и stalled циклов. Вооруженные этими метриками разработчики и админы могут решить как правильнее тюнинговать их приложения и системы.
Исследование роста утилизации процессора: как мы мигрировали с CentOS 7 на Oracle Linux 7
Когда мы мигрировали один из наших микросервисов с CentOS 7 с ядром 4.19 на Oracle Linux 7 с ядром 5.4, мы заметили рост утилизации процессора на наших stress/performance-тестах. В статье я расскажу, как мы исследовали причины роста утилизации процессора сначала в user-space, а потом и в kernel-space и о том, к какому результату это нас привело.
Проблема
Для начала немного о том, что представляет собой наш микросервис: это in-house L3/L4 balancing router. Ядро сервиса состоит из eBPF/XDP [1] приложения, которое загружается в ядро Linux («живет» в SOFTIRQ) и решает задачи балансировки/роутинга сетевых пакетов до конечных бэкендов — это наш data plane. Cервис похож на katran [2] у Facebook, maglev [3] у Google, unimog [4] у Cloudflare и glb [5] у Github, но за небольшим исключением, что выгодно отличает нас от остальных. Серверы, на которых расположен микросервис (далее по тексту «ноды»), соединены между собой в кластер, а также соединены по BGP с L3 Juniper роутерами и получают от них сетевые пакеты с помощью ECMP. Сами кластеры располагаются в разных дата-центрах и соединены между собой, каждая нода в кластере знает состояние всех соединений во всех присоединенных кластерах. За это отвечает приложение на Erlang совместно с приложением на Golang как адаптером для работы с eBPF/XDP — это наш control plane. Таким образом, каждая нода готова балансировать/роутить пакеты в кластере, если все остальные ноды в кластере выйдут из строя. Каждый кластер в свою очередь готов балансировать/роутить пакеты других присоединенных кластеров, если они выйдут из строя.
В ходе миграции на наших stress/performance-тестах, которые генерируют высокий PPS, мы заметили рост утилизации процессора примерно на 10% на Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek по сравнению с CentOS 7 с ядром 4.19.125-1:
CentOS 7 с ядром 4.19.125-1 (the plot is stacked) на str01-t01-**r01 Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek (the plot is stacked) на str01-t01-**r02
Тут в первую очередь нам интересен рост утилизации процессора в SOFTIRQ: 13% vs. 26%. SOFTIRQ показывает время, затрачиваемое процессором при обработке некоторых soft deferred задач. Таких как обработка сетевых пакетов (rx/tx), RCU, таймеров и tasklet’ов. Следовательно, нам нужно выяснить, на что больше всего процессорного времени тратится в SOFTIRQ?
Исследование в user-space
Чтобы определить, на какой тип задач (обработка сетевых пакетов (rx/tx), RCU, таймеров и tasklet’ов) процессор тратит больше всего времени в SOFTIRQ, достаточно заглянуть в файл /proc/softirqs. Для нас интересны в первую очередь NET_TX и NET_RX. Пожалуйста, обратите внимание — файл содержит статистику по разным типам задач SOFTIRQ с начала старта системы и в данном случае, нам интересна только скорость роста этих значений:
Из листингов выше видно, значения NET_TX и NET_RX во времени растут примерно с одинаковой скоростью.
Но все-таки, кто же из них стал работать медленнее и как следствие тратить больше процессорного времени? Чтобы это определить, можно воспользоваться набором скриптов из пакета BCC. Скрипт /usr/share/bcc/tools/softirqs из этого пакета просуммирует время, затрачиваемое каждыми типом задач в SOFTIRQ в течении 10 секунд. Пожалуйста, обратите внимание, оригинальный скрипт был модифицирован для сбора статистики только на 0-м ядре процессора для большей точности и гранулярности:
После анализа листингов выше видно — основное время затрачивается при обработке входящего трафика — NET_RX. И самое странное, время в обоих случаях почти одинаково —
266ms (str01-t01-**r01) vs.
271ms (str01-t01-**r02). Т.е. примерно от
271ms тратится на NET_RX на 0-м ядре процессора (как и на всех остальных ядрах, очевидно) в каждую секунду времени. Но! в процентном соотношении это не 13% vs. 26% как мы видели на графиках выше. It seems like we need to go deeper. 🙁
Исследование в kernel-space
Для дальнейшего анализа и понимания проблемы, нужно немного углубиться в то, как работает SOFTIRQ. SOFTIRQ запускается когда:
system call возвращает управление в user-space;
hardware interrupt handler возвращает управление в ядро.
Упрощённо, общий процесс работы NET_RX и обработки сетевых пакетов выглядит следующим образом: драйвер сетевого интерфейса регистрирует свой callback как NAPI poll-функцию — vmxnet3_poll_rx_only в нашем случае. При поступлении очередного пакета драйвер информирует (нотифицирует) NAPI, о том, что один из softirq callback’ов готов к работе. Ядро вызывает _do__softirq функцию, которая вызывает net_rx_action функцию, которая уже в свою очередь вызывает NAPI poll-функцию vmxnet3_poll_rx_only. Далее эта функция в течении некоторого времени вычитывает сетевые пакеты из DMA-памяти сетевого интерфейса. Время работы функции обусловлено временным бюджетом (максимум до 2ms) или количеством пакетов, которые можно вычитать (до 64 пакетов за одну итерацию). В случае, если временной бюджет еще не исчерпан, и в DMA-памяти сетевого интерфейса есть еще пакеты, которые можно вычитать, происходит очередная итерация чтения пакетов. После этого ядро вызывает net_rps_send_ipi функцию (эта функция используется RPS подсистемой). И наконец вызывается функция process_backlog для непосредственной обработки вычитанных пакетов ядром (в контексте этой функции и работает ядро нашего сервиса — eBPF/XDP приложение) [6] [7] [8].
Для дальнейшего анализа нужно собрать stacktrace (с 0-го ядра) процессора на str01-t01-**r01 в течение 10 секунд:
Для наглядности полученный stacktrace я конвертировал во FlameGraph:
FlameGraph stacktrace’a ядра CentOS 7 с ядром 4.19.125-1 на str01-t01-**r01
И то же самое на str01-t01-**r02:
Полученный stacktrace также сконвертируем во FlameGraph:
FlameGraph stacktrace’a ядра Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek на str01-t01-**r02
Используя функцию поиска — search во FlameGraph — можно найти все вызовы функции net_rx_action и время (в процентах) затраченное ей на 0-м ядре процессора. Время в обоих случаях почти одинаково —
23.1% (str01-t01-**r01) vs.
подобные stacktrace’ы также можно собрать с помощью скриптов из пакета BCC
Следующим шагом для получения более полной картины было проведено инструментирование функциий _do__softirq, net_rx_action, vmxnet3_poll_rx_only, net_rps_send_ipi и process_backlog в течение 60 секунд с помощью bpftrace c использованием скрипта softirqlat.bt [10]:
Обобщая результаты
Среднее время затрачиваемое в секунду на обработку трафика в NET_RX в обоих случаях почти одинаково:
Среднее время (в процентах) затрачиваемое в секунду на обработку трафика функцией net_rx_action в обоих случаях почти одинаково:
Среднее время затрачиваемое в секунду в функциях _do__softirq, net_rx_action, vmxnet3_poll_rx_only, net_rps_send_ipi и process_backlog в обоих случаях почти одинаково. Отклонение времени в vmxnet3_poll_rx_only на некоторых ядрах процессора зависит от количества пакетов полученных на этом ядре (если быть более точным — на rx-queue ассоциированной с соответствующим ядром процессора);
Выглядит так, что проблема где-то в SOFTIRQ аккаунтинге.
Исследование SOFTIRQ accounting’а
После чтения исходных кодов ядра Linux методом пристального вглядывания, стало понятно, что SOFTIRQ accounting производится в разных функциях, одна из них — irqtime_account_process_tick, и для нас она наиболее интересна. Комментарий в этой функции сообщает следующее:
When returning from idle, many ticks can get accounted at once, including some ticks of steal, irq, and softirq time.
Эта функция может быть включена/отключена на уровне конфига ядра с помощью опции CONFIG_IRQ_TIME_ACCOUNTING. Когда она включена, SOFTIRQ accounting производится более аккуратно, и наоборот — когда эта опция отключена, тики процессора могут быть подсчитаны неточно 🙁
Выглядит так, что CentOS 7 с ядром 4.19.125-1 считает тики процессора не точно, а Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek показывает более реальную статистику утилизации процессора в SOFTIRQ. Для подтверждения этой гипотезы было собрано новое ядро Oracle Linux 7 5.4.17-2102.200.13.el7uek с отключенной опцией CONFIG_IRQ_TIME_ACCOUNTING (это было сделано на str01-t01-**r03):
Левый график — нагрузка на str01-t01-**r01 с CentOS 7 с ядром 4.19.125-1 с отключенной CONFIG_IRQ_TIME_ACCOUNTING опцией;
Центральный график — нагрузка на str01-t01-**r02 с Oracle Linux 7 с ядром 5.4.17-2102.200.13.el7uek с включенной CONFIG_IRQ_TIME_ACCOUNTING опцией;
Правый график — нагрузка на str01-t01-**r03 с Oracle Linux 7 с пересобранным ядром 5.4.17-2102.200.13.el7uek с отключенной CONFIG_IRQ_TIME_ACCOUNTING опцией.
Заключение
Теперь можно точно сказать — Oracle Linux 7 c ядром 5.4.17-2102.200.13.el7uek и включенной опцией CONFIG_IRQ_TIME_ACCOUNTING более точно производит подсчет тиков процессора и показывает более реальную статистику утилизации процессора, чем CentOS 7 с ядром 4.19.125-1 и выключенной опцией CONFIG_IRQ_TIME_ACCOUNTING.
Спасибо, что прочли до конца, я буду рад вопросам и постараюсь на них ответить в комментариях.
Мониторинг использования CPU на сервере Linux
Объем памяти, размер кеша, скорость чтения и записи на диск, скорость и доступность вычислительной мощности – это ключевые элементы, влияющие на производительность любой инфраструктуры.
Данное руководство ознакомит с базовыми понятиями мониторинга CPU. Вы узнаете, как использовать утилиты uptime и top, чтобы узнать о нагрузке и использовании ЦП.
Требования
Основные понятия
Прежде чем приступить к работе с утилитами, нужно понять, как измеряется использование ЦП и к каким результатам нужно стремиться.
Загрузка и использование ЦП
Загрузка (CPU Load) и использование процессора (CPU Utilization) – два разных способа взглянуть на использование вычислительной мощности компьютера.
Чтобы оценить основное различие между ними, попробуйте представить, что процессоры – это кассиры в продуктовом магазине, а задачи – это клиенты, которых нужно обслужить. Загрузка процессора – это, по сути, одна очередь, в которой клиенты ждут, пока освободиться один из кассиров. Нагрузка – это в данном случае количество клиентов в очереди, включая тех, что уже на кассе. Чем длиннее очередь, тем дольше ждать.
Использование ЦП оценивает исключительно занятость кассиров и не знает, сколько клиентов в очереди.
Если говорить конкретнее, задачи создают очередь за ресурсами процессоров. Когда подходит очередь той или иной задачи, она должна получить определенное количество времени обработки. Если задача была выполнена, он снимается; в противном случае она возвращается в конец очереди. После этого обрабатывается следующая задача в очереди.
Загрузка ЦП – это длина очереди запланированных задач, включая те, что находятся в обработке. Задачи могут переключаться в пределах миллисекунд, поэтому один снапшот загрузки не так полезен, как среднее значение из нескольких снапшотов, взятых за определенный период времени. Потому загрузка ЦП часто представляется как среднее значение.
Загрузка процессора отображает спрос на процессорное время. Высокий спрос может привести к сбоям и ухудшению производительности.
Использование ЦП сообщает, насколько загружены процессоры, не беря во внимание количество ожидающих задач. Мониторинг использования ЦП может отображать тенденции во времени, выделять пики использования процессора и выявлять нежелательную активность на сервере.
Ненормированные и нормированные значения
В одной процессорной системе общая емкость всегда равна 1. В многопроцессорной системе данные могут отображаться двумя разными способами. Суммарная емкость всех процессоров рассчитывается как 100% независимо от количества процессоров, такое значение считается нормированным. Другой вариант предлагает считать каждый процессор как единицу, так что 2-процессорная система в полном объеме имеет емкость 200%, 4-процессорная система в полном объеме имеет мощность 400% и т. д.
Чтобы правильно интерпретировать загрузку или использование CPU, нужно знать количество процессоров на сервере.
Отображение информации о ЦП
Чтобы узнать количество процессоров, можно использовать команду nproc с опцией –all. Без этого флага команда отобразит количество обрабатывающих блоков, доступных для текущего процесса, что будет меньше общего количества процессоров.
В большинстве современных дистрибутивов Linux также можно использовать команду lscpu, которая отображает не только количество процессоров, но и архитектуру, имя модели, скорость и многое другое:
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 1
Core(s) per socket: 1
Socket(s): 2
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz
Stepping: 2
CPU MHz: 1797.917
BogoMIPS: 3595.83
Virtualization: VT-x
Hypervisor vendor: KVM
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 30720K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl eagerfpu pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm vnmi ept fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid xsaveopt arat
Знание точного количества процессоров важно для интерпретации результатов тех или иных утилит.
Оптимальные значения загрузки и использования ЦП
Оптимальное значение использования ЦП зависит от того, какую работу должен выполнять сервер. Стабильно высокое использование процессора негативно влияет на отзывчивость системы. Часто приложениям и пакетным заданиям с интенсивными вычислениями необходим весь или почти весь объем ЦП. Однако, если система должна обслуживать веб-страницы или поддерживать интерактивные сеансы сервисов (например, SSH), тогда может понадобиться свободная вычислительная мощность.
Как и во многих других аспектах производительности, ключом к оптимизации ресурсов является изучение потребностей сервисов системы и мониторинг непредвиденных изменений.
Мониторинг ЦП
Существует множество инструментов для получения данных о состоянии ЦП системы. Мы рассмотрим две команды: uptime и top. Обе утилиты являются частью стандартной установки большинства популярных дистрибутивов Linux и обычно используются для исследования загрузки и использования ЦП.
Примечание: Следующие примеры выполнены на 2-ядерном сервере.
Утилита uptime
Команда uptime позволяет отследить загрузку процессора. Она может быть полезна, если система медленно реагирует на интерактивные запросы (вероятно, ей не хватает системных ресурсов).
Утилита uptime сообщает следующие данные:
uptime
14:08:15 up 22:54, 2 users, load average: 2.00, 1.37, 0.63
В этом примере команда была запущена в 14:08 на сервере, который работал почти 23 часа. При запуске uptime подключились два пользователя. Этот сервер имеет 2 процессора. За минуту до запуска команды средняя загрузка процессора была 2,00, что означает, что в течение этой минуты процессоры использовали в среднем две задачи, а ожидающих задач не было. Среднее значение загрузки з а5 минут указывает на то, что в течение некоторого интервала времени один из процессоров бездействовал около 60% времени. Среднее за 15 минут значение указывает на то, что было доступно больше времени обработки. Вместе эти три значения показывают увеличение загрузки за последние пятнадцать минут.
Утилита uptime сообщает полезные средние значения загрузки ЦП, но для того, чтобы получить более подробную информацию, нужно использовать top.
Утилита top
Как и uptime, утилита top доступна как в Linux, так и в Unix-системах, но помимо отображения средних значений нагрузки для заданных временных интервалов она предоставляет информацию о потреблении ЦП в реальном времени, а также другие полезные показатели производительности. Если uptime запускается и сразу завершает работу, top работает на переднем плане и регулярно обновляется.
Заглавный блок
Первые пять строк содержат сводную информацию о процессах на сервере:
Первая строка почти идентична выводу утилиты uptime. Здесь показаны средние значения за одну, пять и пятнадцать минут. Эта строка отличается от вывода uptime только тем, что вначале указывается утилита top и время последнего обновления данных.
Вторая строка предоставляет краткий обзор состояния задач: общее количество процессов, количество запущенных, спящих, остановленных и зависших процессов.
Третья строка говорит об использовании ЦП. Эти цифры нормируются и отображаются в процентах (без символа %), так что все значения в этой строке должны составлять до 100% независимо от количества процессоров.
Четвертая и пятая строки сообщают об использовании памяти и swap соответственно.
После заглавного блока следует таблица с информацией о каждом отдельном процессе, которую мы вскоре рассмотрим.
Давайте рассмотрим подробнее все компоненты строки CPU.
Таблица процессов
Все процессы, выполняемые на сервере, независимо от их состояния перечисляются под заглавным блоком вывода. Ниже приведены первые шесть строк таблицы процессов из предыдущего примера. По умолчанию таблица процессов сортируется по% CPU, поэтому в начале находятся процессы, которые потребляют больше CPU.
Столбец %CPU представлен как процентное значение, но он не нормируется, поэтому в этой двухъядерной системе общее количество всех значений в таблице процессов должно составлять до 200%, если оба процессора полностью используются.
Примечание: Если вы предпочитаете работать с нормированными значениями, вы можете нажать SHIFT + I, и отображение переключится с режима Irix в режим Solaris. Этот режим выводит ту же информацию, которая усредняется по всему количеству процессоров, так что используемая сумма не будет превышать 100%. Перейдя к режиму Solaris, вы получите краткое сообщение о том, что режим Irix выключен.
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
10081 8host 20 0 9528 96 0 R 50.0 0.0 0:49.18 stress
10082 8host 20 0 9528 96 0 R 50.0 0.0 0:49.08 stress
1439 root 20 0 223832 27012 14048 S 0.2 0.7 0:11.07 snapd
1 root 20 0 39832 5868 4020 S 0.0 0.1 0:07.31 systemd
Заключение
Теперь вы умеете работать с утилитами uptime и top и интерпретировать их вывод.