Профилирование ядра с perf — от основ до экспертов

В этом посте разберёмся, что такое профилирование ядра с помощью perf, как оно реально может помочь в жизни любого админа, девопса или просто энтузиаста серверных технологий. Я расскажу, почему perf — это не только инструмент для гуру, но и отличная палка-выручалочка для тех, кто хочет быстро и по делу разобраться, что тормозит сервер, почему контейнеры вдруг едят больше CPU, или как найти узкое место в продакшн-сервисе. Всё будет на реальных примерах, с лайфхаками, ошибками, сравнениями и даже с парой неочевидных приёмов.

О чём этот пост и зачем он тебе?

Если ты когда-нибудь сталкивался с ситуацией, когда сервер “тормозит”, нагрузка на ядро растёт, а top или htop показывают только загадочный system или softirq — этот пост для тебя. perf — инструмент, который позволяет не просто посмотреть, кто ест CPU, а реально “просветить” ядро Linux и увидеть, где именно тратится процессорное время: в каком системном вызове, драйвере, модуле, или даже конкретной строке кода.

Всё это — must-have для тех, кто арендует VPS, держит облачные инстансы, занимается контейнерами на Docker или Kubernetes, или просто хочет оптимизировать свой выделенный сервер (кстати, если нужен сервер — VPS или dedicated).

Почему профилирование ядра важно?

• Помогает находить узкие места, которые не видны обычными мониторингами
• Позволяет понять, почему сервис медленно работает (а не просто “где-то тормозит”)
• Даёт возможность оптимизировать приложение или систему без угадываний
• Позволяет быстро реагировать на инциденты, особенно если сервер в облаке и ресурсы стоят денег

Как это работает? Алгоритмы и структура perf

perf — это инструмент из ядра Linux, который работает на уровне hardware performance counters (аппаратных счётчиков производительности) и software events. Он умеет снимать статистику не только по приложениям, но и по всему ядру, включая модули, драйверы, system calls, soft/hard IRQs и т.д.

В основе работы — механизм sampling: perf периодически делает “снимки” состояния процессора, чтобы понять, где сейчас выполняется код (в ядре, в юзерспейсе, в драйвере и т.д.). Всё это можно собрать в отчёт, который покажет, какие функции или участки кода чаще всего “забивают” CPU.

• Sampling — снимает сэмплы по таймеру или по событиям (например, каждые N инструкций)
• Tracing — позволяет отследить последовательность вызовов, но это тяжелее и реже нужно
• Stack unwinding — можно получить стек вызовов, чтобы видеть не только “где”, но и “как туда попали”

Краткая архитектура perf:

• perf_events — подсистема ядра, которая собирает события
• perf tool — утилита командной строки для сбора и анализа профилей
• perf.data — бинарные файлы со сэмплами, которые можно анализировать оффлайн
• perf report — просмотр собранных данных в виде “плоского” списка или call-graph

Как быстро и просто всё настроить? Практические советы

Самое классное в perf — он уже встроен почти во все современные дистрибутивы Linux. Но есть нюансы:

• На VPS и облаках иногда ядро собрано без поддержки perf, либо стоит ограничение на чтение hardware counters (security reason)
• Для глубокого анализа ядра нужны отладочные символы (debuginfo пакеты)
• Для stack traces желательно собирать perf с поддержкой libunwind

1. Установка perf

# Debian/Ubuntu:
sudo apt install linux-tools-common linux-tools-$(uname -r)

# CentOS/RHEL:
sudo yum install perf

# Альтернатива — собрать из исходников:
git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
cd linux/tools/perf
make && sudo make install

2. Проверка поддержки и прав

# Проверяем, что perf работает:
perf list

# Проверяем ограничения ядра:
cat /proc/sys/kernel/perf_event_paranoid
# 0 — полный доступ, 2 — только свои процессы, 3 — почти ничего
# Для профилирования ядра лучше временно выставить 1 или 0:
sudo sysctl kernel.perf_event_paranoid=1

3. Быстрое профилирование ядра

Самая простая команда, чтобы понять, что грузит ядро:

sudo perf top

Это как top, только для ядра: в реальном времени показывает функции, которые чаще всего вызываются.

4. Сбор профиля для анализа

# Снимем 10 секунд профиля по всему ядру:
sudo perf record -a -g -- sleep 10

# Анализируем:
sudo perf report

Ключи:

• -a — по всем CPU
• -g — с call-graph (стек вызовов)

Для профилирования только одного процесса:

sudo perf record -p <PID> -g -- sleep 10

5. Установка отладочных символов

Чтобы видеть не только адреса, но и имена функций:

# Ubuntu/Debian:
sudo apt install linux-image-$(uname -r)-dbgsym

# CentOS/RHEL:
sudo debuginfo-install kernel

Примеры, кейсы: что может показать perf

Положительные кейсы

• Один раз perf помог найти баг в драйвере сетевой карты, который жрал 30% CPU — обновление драйвера решило проблему
• На VPS с OpenVZ perf показал, что ядро тратит кучу времени на page faults из-за нехватки RAM — апгрейд помог

Отрицательные кейсы

• На некоторых облаках perf не работает из-за ограничений hypervisor — приходится использовать другие методы
• Без debuginfo отчёты perf выглядят как набор адресов — бесполезно для анализа

Ошибки новичков и мифы

• Миф: perf нужен только для программистов ядра. Факт: для админов и девопсов это must-have, чтобы понять, где реально тормозит сервер.
• Ошибка: Запускать perf без sudo — часть событий не будет видна.
• Ошибка: Не ставить debuginfo — профили будут бесполезны.
• Ошибка: Пытаться профилировать ядро на облачных VPS без поддержки perf — ничего не получится, ищи альтернативы (например, bcc или eBPF).
• Миф: perf сильно грузит систему. Факт: В режиме sampling overhead обычно 1-5%, можно использовать даже на проде (но аккуратно).

Похожие решения и альтернативы

• ftrace — встроенный трейсинг, мощнее, но сложнее для новичков
• eBPF/bpftrace — новый тренд, можно писать свои скрипты для профилирования, но требует современного ядра
• systemtap — старый, мощный, но сложный и требует модулей ядра
• oprofile — альтернатива perf, но менее дружелюбен

Официальные ссылки:

• perf wiki
• Brendan Gregg’s perf page

Статистика и сравнения

Интересные факты и лайфхаки

• perf можно запускать даже внутри Docker-контейнера, если выставить --privileged и пробросить /proc
• perf умеет профилировать не только CPU, но и кеши, branch mispredicts, page faults, context switches
• Можно визуализировать call-graph с помощью FlameGraph от Brendan Gregg (github.com/brendangregg/Flamegraph)
• perf отлично интегрируется с CI/CD: можно автоматически собирать профили после деплоя и сравнивать их между релизами
• perf поддерживает экспорт данных в текстовый и CSV-формат для автоматизированного анализа

Автоматизация и скрипты: новые возможности

• Можно автоматизировать сбор профилей по расписанию (cron) и отправлять отчёты в Slack/Telegram
• Использовать perf для автотюнинга: скрипт анализирует, где bottleneck, и автоматически предлагает оптимизации
• Интеграция с Prometheus/Grafana через perf_exporter — мониторинг в реальном времени
• Собирать профили на тестовом окружении и сравнивать их с продом для поиска регрессий

Выводы и рекомендации

• Если ты занимаешься настройкой, обслуживанием или оптимизацией серверов — perf должен быть в твоём арсенале.
• Он прост в освоении, но при этом даёт информацию, которую не покажет ни один поверхностный мониторинг.
• Используй perf для быстрой диагностики проблем в ядре, драйверах, контейнерах, БД и сетевых сервисах.
• Не забывай про отладочные символы — без них профили бесполезны.
• Для облаков и VPS — заранее проверь, поддерживается ли perf, иначе ищи альтернативы (eBPF, ftrace, bcc).
• Автоматизируй сбор и анализ профилей — это даст тебе конкурентное преимущество и спокойствие на дежурстве.

Если нужен сервер для экспериментов — VPS или dedicated — и вперёд, к новым вершинам профилирования!