Linux: почему растёт high system CPU — perf, softirq, ksoftirqd и cgroups

Иногда сервер выглядит «живым»: запросы идут, диски не забиты, памяти хватает, но в top/htop растёт sy (system time), а пользовательские процессы не объясняют нагрузку. В таких инцидентах важно не «тюнить всё подряд», а понять: CPU тратится на ядро (системные вызовы), обработку прерываний, сеть, блокировки, cgroups/контейнеры или конкретный драйвер.

Ниже — практический чеклист: от быстрых сигналов (softirq, ksoftirqd) до профилирования (perf top) и отдельного слоя — ограничений cgroups cpu.

Что значит high system CPU и почему это не всегда «плохо»

sy в top — время, которое CPU проводит в коде ядра. Типовые причины:

• Сетевая обработка: пакеты, маршрутизация, туннели, балансировщики, проксирование.

• softirq: отложенная обработка прерываний (часто сеть).

• Драйверы/IRQ: перекос прерываний по ядрам, высокий PPS, особенности RSS/RPS/XPS.

• Блокировки/спинлоки внутри ядра (реже, но бывает).

• cgroups: не «создают» system time напрямую, но меняют картину и провоцируют очереди/перекосы по CPU.

Нормальная ситуация: если вы шифруете трафик, обрабатываете много мелких пакетов или активно фильтруете/маршрутизируете, ядро действительно будет работать больше. Ненормальная — когда рост sy не коррелирует с нагрузкой или сопровождается падением производительности.

Быстрый триаж: за 2–3 минуты понять, куда копать

1) Смотрим top/htop: есть ли «явный виновник»

Если вверху списка процессов виден ksoftirqd/N, это сильный маркер проблем с обработкой softirq/прерываний. Но отсутствие ksoftirqd не означает, что softirq нет: пока система справляется, softirq часто выполняется в контексте текущего потока.

2) Смотрим softirq и IRQ: /proc/softirqs и /proc/interrupts

Два файла дают максимум сигнала за минимум времени:

cat /proc/softirqs
cat /proc/interrupts

Что искать:

• В /proc/softirqs строки NET_RX и NET_TX растут заметно быстрее остальных — почти наверняка упираетесь в сетевой путь.

• В /proc/interrupts один IRQ «прибит» к одному CPU (растёт одна колонка) — перекос по прерываниям и/или очередям NIC.

Если softirq растёт быстро, а нагрузка распределена неравномерно по ядрам, проблема обычно не в приложении, а в том, как хост обслуживает сетевые события: affinity, RSS/RPS, irqbalance, драйвер.

3) Проверяем irqbalance

irqbalance пытается распределять IRQ по ядрам. На одних профилях нагрузки он спасает, на других мешает (например, когда вы вручную настроили affinity или вам критична стабильная привязка очередей NIC к ядрам).

systemctl status irqbalance
ps aux | grep -E 'irqbalance' | grep -v grep

Практика:

• Если irqbalance выключен, а в /proc/interrupts явный перекос — включение часто даёт быстрый эффект.

• Если включён, но IRQ всё равно «прилипают» или прыгают хаотично — проверяйте настройки NIC (очереди/RSS), а для диагностики иногда имеет смысл временно остановить irqbalance и сравнить картину (осознанно и с фиксацией «до/после»).

ksoftirqd: что это и почему он «ест CPU»

ksoftirqd — kernel thread, который подхватывает обработку softirq, когда её слишком много для выполнения «сразу» в контексте прерывания/текущего потока. Упрощённо: пока система успевает, softirq отрабатывается «на месте». Когда не успевает — начинает активнее работать ksoftirqd, и вы уже видите его в top.

Типовые причины высокой загрузки ksoftirqd:

• Много маленьких пакетов (высокий PPS): профили, похожие на DDoS, но это не обязательно атака — часто так выглядит прокси/балансировщик/логирование.

• NAT/conntrack и тяжёлые правила в firewall (iptables/nftables).

• Неправильное число очередей NIC и плохой RSS: всё падает в одну очередь и «жарит» одно ядро.

• Неудачные настройки offload (GRO/LRO/TSO/GSO) для вашего трафика и окружения.

Важно: «убрать ksoftirqd» нельзя — это симптом. Лечить нужно причину: распределение IRQ, профиль трафика, фильтрацию, offload и очереди.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Профилирование: как применять perf top при high system CPU

Когда уже видно, что время уходит в kernel space, следующий шаг — понять, какие функции ядра «горячие». Для этого удобно использовать perf top.

Установка и базовый запуск

Debian/Ubuntu:

apt update
apt install -y linux-tools-common linux-tools-generic

RHEL-подобные:

dnf install -y perf

Запуск:

perf top

Если основная нагрузка именно в ядре, в выдаче вы увидите kernel symbols: сетевой стек, обработчики прерываний, блокировки, копирование буферов, криптографию и т.д.

Два полезных режима для system time

1) С фокусом на ядре (часто достаточно):

perf top -K

2) По конкретному CPU (если «горит» одно ядро из-за IRQ):

perf top -C 0

Если одно ядро забито прерываниями/softirq, общий perf top может «размыть» картину.

Как интерпретировать результат perf top (практично)

Не нужно «гуглить каждую функцию». Достаточно классифицировать, что доминирует:

• Сетевые функции (RX/TX, IP, TCP) — проверяем PPS, перекос IRQ, RSS/RPS/XPS, правила firewall/NAT.

• Криптография — возможен упор в TLS/IPsec/шифрование (часто параллельно видна и user-нагрузка у процессов терминации).

• Memory/copy — возможны лишние копирования (проксирование, большие объёмы), проверяем offload и параметры сокетов/буферов.

perf top быстро отвечает на вопрос «CPU уходит в сеть, в блокировки, в драйвер или во что-то ещё?». Это сокращает время до правильной гипотезы.

Связка softirq + IRQ: где чаще всего спрятан корень проблемы

Проверяем перекос по прерываниям

Снимите «срез» два раза с интервалом 10–30 секунд и сравните рост конкретных строк по CPU:

cat /proc/interrupts
sleep 15
cat /proc/interrupts

Если IRQ сетевой карты (часто подписан именем интерфейса/очереди) растёт почти в одной колонке — значит весь RX/TX обслуживает одно ядро. Это типичная причина high system CPU на многопроцессорных серверах.

irqbalance: включить, настроить или не трогать

Дальше возможны варианты:

• Оставить irqbalance включённым, если он реально выравнивает нагрузку и не ухудшает latency.

• Для latency-чувствительных сервисов иногда полезнее зафиксировать IRQ и связанные процессы на «свои» ядра, но это ручная инженерия и требует измерений.

Лучше сначала понять картину через /proc/interrupts и perf top, а уже потом менять настройки.

Полезное дополнение по лимитам systemd (часто пересекается с CPU/изоляцией): лимиты CPU и памяти для systemd-сервисов.

cgroups CPU: как ограничения меняют картину high system CPU

Контейнеры и systemd-юниты живут в cgroups. Из-за этого легко попасть в ловушку: вы видите высокий sy «в системе», но конкретный сервис не выглядит виноватым — потому что он ограничен по CPU и не может «показать» высокую user-нагрузку. При этом очередь сетевой обработки и сопутствующие работы ядра остаются на хосте.

Что проверить в первую очередь

Определите, какая версия cgroups используется:

stat -fc %T /sys/fs/cgroup

Для systemd-сервисов полезно посмотреть ограничения:

systemctl show your.service -p CPUQuota -p AllowedCPUs -p AllowedMemoryNodes

И фактическое потребление/троттлинг (cgroup v2):

cat /sys/fs/cgroup/system.slice/your.service/cpu.stat

В cpu.stat обращайте внимание на nr_throttled и throttled_usec: если они быстро растут, сервис регулярно упирается в лимит CPU.

Почему троттлинг может усилить «system time»

Когда сервису «режут» CPU, он дольше разгребает очередь (запросы, сеть, фоновые задачи). В итоге растут очереди и накладные расходы, а в метриках получается «system CPU высокий, а полезной работы меньше».

Практический вывод: при high system CPU на хосте с контейнерами всегда проверяйте, не загнали ли вы важный компонент в слишком жёсткий cgroups cpu-лимит.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Мини-чеклист: типовые сценарии и что делать дальше

Сценарий A: растёт NET_RX/NET_TX в /proc/softirqs

• Проверьте перекос IRQ в /proc/interrupts.

• Проверьте состояние irqbalance.

• Запустите perf top -C N на «горячем» ядре.

Сценарий B: в top видно ksoftirqd, но трафик «не огромный»

• Смотрите не только Мбит/с, но и PPS: «миллионы пакетов» убивают CPU быстрее, чем «мегабиты».

• Проверьте firewall/NAT/conntrack — тяжёлые правила и большой state часто дают высокий kernel overhead.

• Через perf top убедитесь, что горячие функции действительно сетевые, а не, например, блокировки.

Сценарий C: приложение в контейнере «медленное», а sy на хосте высокое

• Проверьте лимиты cgroups cpu и cpu.stat на троттлинг.

• Сравните, не «зажали» ли вы ingress/sidecar/прокси, который реально держит нагрузку.

Если проблема проявляется на VPS/VDS и есть подозрение на нехватку CPU в конкретном тарифе, заранее удобно свериться с подбором конфигурации: как выбрать VDS по CPU и памяти.

Практика безопасной диагностики (чтобы не усугубить инцидент)

Инструменты вроде perf обычно безопасны, но на очень загруженных системах любой профайлинг добавляет overhead. Рекомендации:

• Начинайте с коротких срезов и точечных запусков (perf top -C на одном ядре).

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

• Фиксируйте «до/после»: снимки /proc/softirqs, /proc/interrupts, вывод perf top за 30–60 секунд.

Итоги

High system CPU — это не «CPU занят приложением», а сигнал, что ядро выполняет много работы: часто это softirq, сетевой стек и распределение IRQ. Если в top всплыл ksoftirqd, смотрите на /proc/softirqs и /proc/interrupts, а затем подтверждайте гипотезу через perf top. И не забывайте про контекст контейнеров: cgroups cpu и троттлинг могут сделать проблему заметнее и запутать симптомы.

Для продакшена полезная привычка — держать базовые метрики PPS/IRQ/softirq рядом с CPU-графиками и иметь короткий runbook: что смотреть первым, что вторым и какие изменения допускаются без окна работ.