CPU (центральный процессор) — это сердце любой вычислительной системы. Эффективное использование CPU напрямую влияет на производительность приложений и всей системы. Даже если Ваш сервер решает задачи абсолютно не требовательные к вычислениям (хранит архив файлов, к которым раз в месяц кому-то нужен доступ), он все равно не может делать это без использования CPU.
В этой серии статей Кирилл Казарин, Senior DevOps и SRE менеджер, автор телеграм-канала Kazarin.online и спикер курса «Администрирование Linux», рассмотрит ряд аспектов, связанных с CPU в Linux и влияющих на производительность ваших приложений и сервисов с точки зрения CPU, включая такие понятия, как утилизация процессора, load average, многопоточность, NUMA, а также различия между архитектурами x86 и ARM. Цель этой статьи — дать общее представление об использовании ресурсов CPU в Linux.
Статья 1. Утилизация
Начнем с Утилизации CPU. Это показатель того, как используется процессорное время в вашей системе. Какие классы задач потребляют его и в каком процентном соотношении. То есть это буквально ответ на вопрос «кто и как сейчас поедает вычислительный ресурс системы?». Для этого в Linux ядро разделяет все потраченное им время на несколько основных категорий: User space («пользовательское пространство»), System space («системное пространство» или «пространство ядра»), Idle time («время бездействия»), I/O Wait («ожидание ввода-вывода»), Interrupts («аппаратные прерывания»), Soft Interrupts («программные прерывания»).
Подобную статистику может предоставить довольно большое число команд, однако наиболее широко распространенными и привычными вариантами являются top или htop.
us (User CPU time) — время, потраченное на пространство пользователя;
sy (System CPU time) — аналогично, время, потраченное на пространство ядра (системное пространство);
ni (Nice CPU time) — отдельно оцениваемое время, потраченное на процессы из пользовательского пространства, которым кто-то (оператор, скрипт запуска и пр.) занизили приоритет. То есть сделали его задачей с пониженным приоритетом выполнения;
id (Idle) — время простоя (бездействия);
wa (I/O wait) — время, проведенное в ожидании операций ввода-вывода;
hi (Hardware IRQ) — время, потраченное на обработку аппаратных прерываний;
si (Software IRQ) — аналогично, время, потраченное на обработку программных прерываний;
st (Steal Time) — очень интересное значение, о котором мы уже писали в другой статье.
Категории
Давайте сделаем тут небольшую паузу и подробнее разберем часть тезисов. Начнем с «В Linux ядро разделяет это время на категории» — как это происходит? Ядро Linux использует счетчики и таймеры для измерения, в каком же состоянии находится процессор в каждый момент времени. Как мы уже сказали, эти состояния делятся на несколько ключевых категорий:
User Space: время, которое процессор тратит на выполнение пользовательских процессов (приложений). Это время регистрируется, когда процесс работает в режиме пользователя
System Space (Kernel Space): время выполнения операций в режиме ядра. Оно включает выполнение системных вызовов, обработку прерываний и выполнение драйверов
Idle Time: время, когда процессор ничего не делает, и система находится в режиме ожидания. В современных системах процессор может переходить в энергосберегающие состояния
I/O Wait: время, которое процессор проводит в ожидании операций ввода-вывода, таких как доступ к дискам или сетевым устройствам
Interrupts: время обработки аппаратных прерываний
Soft Interrupts: время выполнения программных обработчиков прерываний (softirq)
Используя эти категории, ядро Linux использует несколько механизмов для измерения процессорного времени и оценки — сколько времени было потрачено на ту или иную категорию. Примеры таких механизмов подсчета:
1. Таймеры (Jiffies) — это счётчик системных тиков, который увеличивается на каждом такте системного таймера с заданной частотой. Ядро использует jiffies для измерения времени, потраченного процессором в различных категориях (user, system, idle, iowait и т. д.), обновляя соответствующие счётчики при каждом переключении контекста или обработке событий. Это позволяет ОС отслеживать загрузку CPU, планировать задачи и собирать статистику о работе процессов.
Системный таймер — это аппаратный механизм в процессоре или чипсете, который отправляет прерывания ядру с заданной частотой.
Системный тик — это минимальная единица измерения времени в ядре Linux, определяемая системным таймером.
Каждое прерывание означает, что прошёл один системный тик, и ядро обновляет внутренние счётчики времени.
Каждое прерывание таймера заставляет ядро анализировать текущее состояние CPU и обновлять статистику
Если процесс выполнялся в пользовательском пространстве,
utimeувеличиваетсяЕсли в ядре,
stimeувеличиваетсяЕсли процесс ждал ввода-вывода, увеличивается
iowaitТаким образом, системные тики — это механизм, с помощью которого Linux измеряет использование процессорного времени, переключает контекст задач и управляет планированием процессов.
2. Контекст переключения (Context Switch): при каждом переключении между процессами или задачами ядро фиксирует, какое состояние (user space или kernel space) активно, и обновляет соответствующий счётчик. Планировщик ядра (scheduler) отслеживает начало и окончание выполнения задач.
3. События прерываний: ядро регистрирует аппаратные и программные прерывания (например, I/O запросы), добавляя время их обработки в соответствующую категорию. Время на обработку прерываний добавляется в irq (hardware interrupts) или softirq (software interrupts).
4. Отслеживание состояний процессов: ядро следит за состояниями процессов, такими как «готов к выполнению», «выполняется», «ожидает I/O». Состояния фиксируются в планировщике и используются для обновления метрик iowait (время ожидания ввода-вывода) и idle.
5. Высокоточные таймеры (High-Resolution Timers) — это механизм для более точного измерения времени с микросекундной точностью. Используется в современных версиях Linux для более точного профилирования.
Хранение результатов
Собранные таким образом данные нужно как-то сохранять и обновлять. Для этого ядро использует множество мест. Так например, если мы говорим про работающие процессы, то для каждого из них подобная информация будет сохранена внутри структуры данных task_struct, представляющая собой так называемый Process Control Block — объект процесса, используемый операционной системой чтобы управлять им и хранить всю информацию о нем. Так вот в ней, в том числе, содержится ряд счетчиков времени, показывающих, например, сколько процессорного времени было потрачено в User или System mode в ходе выполнения процесса.
Данные о состоянии процессора (user, system, idle, iowait и т. д.) хранятся в структурах данных ядра, доступных через /proc.
Эти данные так же обновляются ядром на основе системных тиков (jiffies) и счётчиков CPU. Например, если мы возьмем самый простой способ посмотреть статистику, мы можем обратиться к файлу /proc/stat, куда Ядро записывает информацию о всех категориях утилизации:
Существует еще ряд файлов-интерфейсов в /proc, позволяющих нам получить такую статистику. Так, например:
/proc/[PID]/stat — детализированная статистика о процессе с PID.
Содержит:
utime, stime: время, потраченное в пользовательском и системном пространстве.starttime: время запуска процесса.nvcsw, nivcsw: добровольные и принудительные переключения контекста.
cat /proc/1234/stat
/proc/[PID]/task/[TID]/stat: аналогично/proc/[PID]/stat, но для потоков (threads) внутри процесса. Может быть полезно для детализированного анализа многопоточных приложений./proc/softirqs: статистика программных прерываний (softirq). Содержит в себе количество обработанных softirq для каждого процессора./proc/interrupts: статистика аппаратных прерываний. Содержит счётчики обработанных аппаратных прерываний для каждого процессора.
К счастью, нам не нужно ежедневно это просматривать вручную — эти источники данных, как и многие другие, за вас самостоятельно парсят top и подобные им утилиты.
Практическая применимость
Вот мы разобрались, что такое утилизация CPU, из чего состоит, примерно поняли, как она считается, куда складируются результаты и как смотреть. Дальше-то что? Зачем нам это может быть нужно?
С моей точки зрения, все ответы будут лежать плюс-минус в одной плоскости. То есть, так или иначе, это связано с анализом состояния вашего сервера и поиском источника нагрузки-потребления. Давайте рассмотрим 2 сценария: поиск проблемы (все было хорошо и тут пошло не по плану) и какого-то вида нагрузочное тестирование, когда вам нужно понять, в какой момент увеличения нагрузки система начинает деградировать по причине нехватки вычислительного ресурса, и куда он уходит в большей степени. Для этого сделаем сравнение в виде вот такой таблицы:
Подводя итог
Отслеживание утилизации CPU и ее составляющих помогает понять, как ресурсы системы используются и где возникают проблемы. Это важно для оптимизации приложений, диагностики узких мест и настройки серверов для устойчивой работы под нагрузкой. Также важно смотреть не только значения в моменте, но и собирать историческую статистику за разные периоды времени, чтобы, в случае возникновения проблемы, сравнить показания на данный момент (например, утро пятницы) с тем же днем и временным интервалом на прошлой неделе и, скажем, в начале этого/конце прошлого месяца. Так мы имеем шанс понять — это у нас нечто совсем новое, чего раньше не было, или уровень утилизации и так был высок, и сегодня мы просто перешагнули некоторый последний рубеж.
Изучить больше продвинутых аспектов конфигурирования, автоматизации, безопасности и оптимизации систем можно на курсе «Администрирование Linux».
