bcc tools на практике: практическое руководство по оптимизации производительности Linux с помощью eBPF

Я покажу шаг за шагом, как я bcc tools использую eBPF для оперативного выявления и устранения узких мест на серверах Linux. При этом я применяю практичные рабочие процессы, измеряю реальные задержки в ядре и связываю события, связанные с ЦП, вводом-выводом и сетью, в единую очистить Анализ причин.

Центральные пункты

• ЭБПФ обеспечивает глубокий трассинг с минимальными накладными расходами.
• bcc tools охватывают процессор, ввод-вывод, сеть и процессы.
• В условиях, близких к производственным Можно использовать без внесения изменений в приложение.
• Контрольный список с десятью инструментами для начала работы.
• Безопасность благодаря системе проверки и четким правилам.

Почему eBPF используется в области оптимизации производительности Linux

Я тянусь к ЭБПФ, потому что я хочу измерять события ядра надежно, выборочно и с минимальными накладными расходами. Классические инструменты показывают итоговые значения, но редко объясняют, почему потоки находятся в режиме ожидания, пакеты отправляются повторно или происходит зависание ввода-вывода; eBPF восполняет этот пробел с помощью конкретные События. Программы запускаются в ядре, верификатор проверяет их заранее, и я могу запустить их без перезагрузки. Таким образом, я сопоставляю вызовы пользовательского пространства с путями ядра и получаю картину, которая позволяет сразу же провести оптимизацию. Те, кто хочет углубить свои знания, найдут обзор в моем кратком введении по Анализ производительности eBPF, в которой описывается взаимосвязь между трассировкой и наблюдаемостью.

Что такое bcc tools и где их найти?

Die bcc tools — это готовые диагностические программы на основе eBPF, которые обычно находятся в каталоге /usr/share/bcc/tools. Я запускаю их прямо из командной строки, получаю понятные стандартные выводы и не нуждаюсь в доработке своих приложений. Этот набор охватывает процессы, системные вызовы, файловые системы, блочный ввод-вывод, сеть, планировщик задач и профилирование, благодаря чему он подходит для производительный Анализ. Поскольку я целенаправленно включаю трассировку, её влияние остается незначительным, а погрешности измерений, вызванные мониторингом, оказываются небольшими. Для более сложных случаев я дополняю инструментарий собственным eBPF или дополнительно использую профили выборки.

Установка и требования

Я устанавливаю bcc Инструменты устанавливаются через систему управления пакетами (bcc-tools или bpfcc-tools) в популярных дистрибутивах. Требуется ядро с поддержкой eBPF (версии 4.x и выше, лучше 4.9+), включенные функции BPF и достаточные права для загрузки программ. На рабочих серверах я заранее проверяю возможности ядра и дистрибутива в отношении eBPF в тестовой среде, чтобы последующие измерения надежный работают. С помощью соответствующих политик я предотвращаю применение профилей безопасности, полностью блокирующих eBPF. Практический обзор настройки и использования представлен в кратких рекомендациях по инструменты анализа eBPF.

Перед запуском: проверка системы и безопасности

Прежде чем проводить измерения в производственной среде, я проверяю базовые возможности хоста. Таким образом я избегаю сбоев при запуске и получаю воспроизводимые результаты.

• Проверка возможностей ядра: uname -r и доступные функции BPF (например, с помощью Feature-Check). Важную роль играют kprobes/tracepoints, BTF (для получения стабильной информации о типах) и события perf.
• Права и политики: Я обеспечиваю, чтобы загрузку eBPF могли осуществлять только авторизованные пользователи (с правами CAP_BPF/CAP_SYS_ADMIN или соответствующей политикой) и чтобы профили LSM не блокировали эту загрузку.
• Параметры системы: kernel.unprivileged_bpf_disabled как правило, активен в производственных средах. Поэтому я сознательно работаю в защищённых сессиях и с чётким аудитом.
• Прозрачные пути: Я считаю, что такие каталоги, как /sys/kernel/debug/tracing и /sys/fs/bpf в поле зрения, чтобы удалить артефакты после проведения измерений.

Такая гигиена позволяет мне проводить измерения целенаправленно и с воспроизводимыми результатами — без побочных эффектов.

Практическое руководство: первые десять инструментов

Для быстрой проверки производительности я использую фиксированную последовательность действий. Это позволяет мне четко выделить причины, связанные с ЦП, вводом-выводом или сетью, и решить, стоит ли углубляться в анализ стеков или таймингов. В таблице приведены основные задачи инструментов и вопросы, на которые я ищу ответы с их помощью. Сначала я сокращаю время выполнения и повторяю измерения, как только у меня возникает подозрение подтвердить хочу. Так я избегаю «слепых зон» и не теряю времени в экстренных Инциденты.

Инструмент	Наблюдается	Типичный вопрос
execsnoop	Новые процессы	Кто запускает кратковременные задания, создающие нагрузку?
opensnoop	Открытие файлов	Какие пути постоянно открываются или регистрируются в журнале?
ext4 медленнее (xfs*, btrfs*, zfs*)	Медленные операции FS	Какие запросы демонстрируют высокие задержки в расчете на объем?
биолатентность	Распределение блочного ввода-вывода	Наблюдаются ли эпизодические или постоянные пики латентности?
biosnoop	Отдельные запросы ввода-вывода	Какой процесс выводит из строя определённые устройства?
cachestat	Поведение кэша страниц	Стоит ли увеличить объем оперативной памяти, или приложение будет работать с перебоями?
tcpconnect	Новые соединения TCP	Кто, как часто и какую услугу заказывает?
tcpaccept	Принятые соединения	Какие серверные сокеты испытывают высокую нагрузку?
tcpretrans	Ретрансляции	Означает ли потеря пакетов, что пути нестабильны?
runqlat	Задержки планировщика	Не ждут ли потоки слишком долго, пока им выделят время процессора?

Я также использую профили для выявления «горячих точек» в пользовательском или ядерном пространстве и агрегирования стеков вызовов. Таким образом я выявляю ресурсоемкие регулярные выражения, неэффективные драйверы или спинлоки, которые затем устраняю в коде или в настройках. Я использую короткие интервалы выборки и сравниваю результаты нескольких прогонов, чтобы отсеять аномальные значения видимый . Такое сочетание общего обзора и углубленного анализа позволяет мне сэкономить много времени на анализе. Затем я повторно тестирую оптимизацию при той же нагрузке.

Расширение: отображение операций вне ЦП, блокировок и времени ожидания

Не всякая высокая задержка связана с ЦП. Часто потоки, находящиеся „вне ЦП“, ожидают операций ввода-вывода, блокировок или пробуждений. В этом случае помогут дополнительные инструменты и профили bcc:

• Анализ вне ЦП: я измеряю, как долго потоки находятся вне ЦП и какие стеки к этому приводят. Это позволяет отделить время вычислений от времени ожидания и выявить источники блокировки.
• Конкуренция за блокировки: я целенаправленно анализирую критические блокировки в ядре и пользовательском пространстве. Длительные задержки или высокая конкуренция указывают на точки сериализации, которые я устраняю (например, с помощью шардинга, более мелкой гранулярности или других структур данных).
• Пути пробуждения: задержки между моментами „был пробужден“ и „снова работает“ указывают на проблемы с планированием и приоритетами или на чрезмерно большие пулы рабочих процессов.

Я сопоставляю эти сигналы с runqlat и биолатентность, чтобы различать причины, связанные с памятью, вводом-выводом и планировщиком.

Гигиена измерений: фильтры, продолжительность, пороговые значения

Чтобы результаты измерений eBPF оставались воспроизводимыми, я руководствуюсь тремя основными правилами:

• Коротко и по существу: сначала я запускаю инструменты на короткое время (например, на 10–30 секунд) и сосредотачиваюсь на подозрительных PID, контейнерах или сокетах.
• Установка пороговых значений: при использовании инструментов „*slower“ я отфильтровываю небольшие задержки, чтобы уменьшить шум и видеть только проблемные вызовы.
• Ограничение частоты событий: я использую селективные фильтры (например, по имени процесса, TID, портам), чтобы снизить частоту событий. Таким образом, накладные расходы остаются минимальными, и я избегаю потери событий.

Только когда я замечаю закономерность, я продлеваю срок действия или расширяю сферу применения. Благодаря этому я получаю чистый и достоверные выборочные данные.

Практический сценарий 1: Необъяснимо высокая нагрузка на ЦП

Если показатели ЦП постоянно остаются на высоком уровне, я начинаю с execsnoop, чтобы выявить кратковременные процессы. Затем с помощью runqlat я измеряю, как долго потоки ожидают времени процессора, и проверяю, не переполнены ли очереди выполнения или не установлены ли приоритеты некорректно. Если время ожидания становится заметным, я уменьшаю количество рабочих процессов, изменяю пулы потоков или разгружаю задания cron, чтобы планировщик захватить могу. С помощью profile я собираю стеки и нахожу настоящие «горячие точки» в библиотеках и в собственном коде. Только после того, как я сопоставлю эти данные, я принимаю решения относительно ограничений, сборки мусора, аффинностей или флагов компилятора.

Практический сценарий 2: задержки ввода-вывода и медленно работающие приложения

Если пользователи жалуются на зависания при низкой загрузке процессора, я проверяю с помощью ext4 медленнее медленные вызовы файловой системы на каждый процесс. Затем с помощью biolatency я анализирую распределение времени блокового ввода-вывода по устройствам, чтобы выявить спорадические пики или постоянные узкие места. biosnoop показывает мне, не генерирует ли отдельная служба чрезмерно много мелких записей, вызывая тем самым образование очередей, которые замедляют работу других процессов. С помощью cachestat я вижу, попадает ли кэш страниц или происходит промах доминировать и увеличение объёма оперативной памяти помогло бы. В итоге я решу, что будет эффективнее: пакетная запись, увеличение буферов или переход на более быстрое хранилище.

Практический сценарий 3: Сетевые пути и микросервисы

В распределенных средах я начинаю с tcpconnect, чтобы измерить установку соединений между службами. Затем с помощью tcpaccept я проверяю, какие серверные сокеты получают особенно много входящих запросов и действуют ли ограничения на стороне прослушивателя. Команда `tcpretrans` выявляет повторные отправки и позволяет отделить транспортные проблемы от ошибок приложения, прежде чем я настрою таймауты и повторные попытки. С помощью этих трёх показателей я могу определить, является ли причиной проблема сеть, приложение или вышестоящий сервис, Латентность . После этого я настраиваю стратегии отката, значения Keepalive, параметры балансировщика нагрузки и размеры буферов.

Эксплуатационная безопасность и надежность eBPF

Я загружаю только надежный Сначала тестирую инструменты и собственные программы eBPF на тестовой среде. Вертификатор ядра блокирует некорректно работающие программы, но я дополнительно устанавливаю ограничения на карты и буферы, чтобы обеспечить четкое ограничение объема памяти. Я сохраняю логи, чтобы отслеживать поведение и побочные эффекты и при необходимости быстро реагировать. Политики определяют, кто имеет право загружать eBPF, чтобы контроль оставался за командой платформы и соблюдались требования безопасности. Эти правила гарантируют, что трассировка в производственных средах Надежный остается прежним и не вызывает никаких неожиданностей.

Контейнерные и Kubernetes-среды

В контейнерах я отделяю системные проблемы от эффектов, связанных с конкретными подами. Для этого я фильтрую измерения по cgroup, пространству имён или диапазону PID. Многие инструменты bcc позволяют фильтровать по именам или ID процессов; в качестве альтернативы я выполняю измерения на хосте и сопоставляю события рабочим нагрузкам с помощью cgroup. Важно:

• Пространство имен PID: PID на хосте и в контейнере различаются. Я сопоставляю идентификаторы или фильтрую по именам процессов/портам.
• Квоты на ресурсы: ограничение производительности ЦП за счёт квот CFS проявляется в виде длительного времени ожидания при неполной загрузке системы. Я замечаю это по runqlat в сочетании с показателями коэффициентов.
• Пространства имён сети: при анализе сокетов я обращаю внимание на правильное пространство имён. Я провожу измерения на интерфейсе хоста и сопоставляю результаты с IP-адресами и портами под.

Таким образом, результаты измерений остаются достоверными, даже если многие рабочие нагрузки выполняются одновременно в непосредственной близости друг от друга.

Интеграция в стеки наблюдаемости

Я не заменяю свой мониторинг, а дополняю его ЭБПФ. Инструменты bcc дают мне глубину, а системы метрик, логи и APM показывают широту; вместе они создают целостную картину. При необходимости я направляю трасы из bcc в конвейеры логов, запускаю создание снимков при инцидентах и документирую результаты в команде. Для выборочного профилирования я использую выборку в дополнение к временным рядам на основе метрик, чтобы выявлять аномалии осязаемые будут. Те, кто предпочитает дополнительно использовать скрипты, найдут в bpftrace на хостинге простой способ отвечать на спонтанные вопросы с помощью мини-скриптов.

Распространенные препятствия — и как я их преодолеваю

• «Noisy Neighbor»: отдельные задания создают кратковременную, но интенсивную нагрузку. execsnoop плюс профили надежно выявляют эти закономерности; я устанавливаю для них временные рамки или выделяю их с помощью квот.
• NUMA и аффинности: высокие задержки, несмотря на наличие свободных ядер, указывают на меж-NUMA-доступы. Я проверяю аффинности процессоров, привязку к памяти и распределение IRQ.
• «горячие точки» IRQ/SoftIRQ: сетевая нагрузка может перегрузить ядра ksoftirqd. Я отслеживаю повторные передачи, распределяю IRQ через RSS/очереди и настраиваю RPS/XPS.
• Эффекты кэша страниц: «холодные» запуски выполняются медленнее. Я учитываю фазы прогрева и сравниваю cachestat-Значения до и после нагрузки.
• Обновления ядра: Kprobes могут изменяться при переходе на новую версию. Я предпочитаю использовать стабильные точки трассировки, заранее провожу тестирование и держу под рукой минимальный набор.

Проверенные на практике рабочие процессы

• Снимок инцидента: 60–120 секунд комбинированного запуска (execsnoop, runqlat, biolatency, tcpretrans, profile). После этого я сосредотачиваюсь на подозрительной подсистеме.
• Базовая процедура: еженедельные краткие измерения на основных маршрутах (например, профиль хранилища и сети). Так я могу своевременно выявлять отклонения.
• Проверка изменений: до и после внесения изменений в конфигурацию я сравниваю одни и те же точки измерения, чтобы количественно оценить эффект.

Непрерывная оптимизация производительности Linux

Я рассматриваю перформанс как непрерывный процесс, а не как Разовая акция. В рамках CI/CD я интегрирую короткие проверки на основе eBPF, чтобы своевременно выявлять регрессии и предотвращать их до развертывания. Во время окон технического обслуживания я измеряю типичные пути прохождения запросов под нагрузкой, создаю базовые показатели и документирую допустимые диапазоны задержек. Таким образом, я быстро выявляю отклонения и избавляюсь от необходимости гадать при устранении инцидентов, поскольку у меня есть сравнительные данные доступно. Эта процедура напрямую способствует обеспечению доступности, контролю затрат и улучшению пользовательского опыта.

Мини-кейс: от симптома к причине за 12 минут

API-кластер сигнализирует о росте задержек до 99p при неизменном показателе RPS. Я запускаю моментальный снимок инцидента: tcpconnect не выявляет никаких аномалий при установке соединения, tcpretrans остаётся низким — а вот сеть, похоже, нет. runqlat сообщает о коротких, но частых задержках; профили отображает «горячие точки» в формате JSON. Параллельно я наблюдаю с помощью cachestat падение показателя попаданий в кэш во время пиковых нагрузок. Эта корреляция позволяет предположить: множество небольших нагрузок, которые синхронно сериализуются и сразу же записываются.

Я проверяю с помощью ext4 медленнее, который показывает операции fsync продолжительностью в несколько миллисекунд на одном и том же томе для процесса API; биолатентность подтверждает эпизодические пики в очереди на затронутом устройстве. Меры по устранению: пакетная обработка записей, увеличение буфера и асинхронная очистка в менее критичных точках. После внедрения задержки 99p снижаются на 35 %, коэффициент попадания в кэш восстанавливается, и runqlat снова демонстрирует узкие распределения.

Резюме для практики

С bcc С помощью инструментов и eBPF я в кратчайшие сроки получаю четкое представление о загрузке ЦП, ввода-вывода и сети, не внося изменений в приложения. Чек-лист, включающий execsnoop, opensnoop, ext4slower, biolatency, biosnoop, cachestat, tcpconnect, tcpaccept, tcpretrans и runqlat, служит хорошей отправной точкой. В дополнение к этому я использую profile, чтобы выявить «горячие точки» и оптимизировать пути выполнения кода. Благодаря четким правилам, ведению журналов и ограничениям использование ядра остается безопасный и понятным. Те, кто последовательно применяет этот метод, быстрее решают проблемы с производительностью, более эффективно планируют ресурсы и снижают затраты на один запрос.