Перейти к содержимому 
С perf top В Linux я за считанные секунды выявляю, какие функции ядра в данный момент занимают больше всего процессорного времени и где возникают узкие места. В этом руководстве я на примере четких шагов покажу, как я выявляю «горячие точки» в режиме реального времени, правильно интерпретирую результаты и на их основе быстро провожу оптимизацию планировщика, сети и памяти.
Центральные пункты
Я считаю, что режим просмотра в реальном времени перфект Отлично подходит для эффективного старта, так как сразу показывает, на что уходит больше всего времени. Процентные доли, указанные рядом с каждым символом, позволяют мне понять, где именно находится «узкое место» в Ядро или находится в пользовательском пространстве. По повторяющимся шаблонам я определяю, что преобладает: блокировки, IRQ, сеть или память. Затем я сужаю область поиска с помощью более глубоких инструментов и проверяю изменения непосредственно под нагрузкой. Так я шаг за шагом улучшаю CPU-повысить загрузку и устойчиво сократить задержки.
- Активные точки доступа выявлять и расставлять приоритеты
- Процентные доли правильно интерпретировать каждую функцию
- Основная сфера деятельности установить: IRQ, блокировки, память
- Рабочий процесс: начало → запись → отчет
- Оптимизации проводить целенаправленную проверку
Что такое «perf top» и для чего он нужен?
Я использую perf top, чтобы во время выполнения задачи сразу увидеть, какие символы занимают наибольшую долю процессорного времени. Этот инструмент обращается к аппаратным счетчикам производительности и с короткими интервалами отображает обновляемый рейтинг самых ресурсоемких функций. По данным журнала «Linux-Magazin», perf поддерживает как профилирование, так и трассировку, что позволяет Вид в реальном времени беспрерывно сочетается с более глубоким анализом. В рамках стандартной процедуры я дополняю моментальный снимок с помощью perf record и perf report, чтобы изучить графики вызовов и точные пути. Таким образом я отвечаю на главный вопрос: где проводит CPU именно в этом месте — в сетевом стеке, в подсистеме памяти, в планировщике или в драйвере?
Установить и запустить perf top
После установки с помощью пакета дистрибутива я запускаю перфект top, как правило, запускается с расширенными правами, чтобы стали видны символы ядра и системные события. Достаточно простого запуска команды „perf top“, чтобы сформировать первоначальный вид в режиме реального времени и выявить доминирующие функции. Если мне нужно сосредоточиться на отдельных процессах, я подключаю PID с параметром -p; для конкретных процессоров я использую параметр -C со списком или диапазоном. События я задаю с помощью параметра -e, например cpu-cycles, instructions или branch-misses, в зависимости от того, какой вопрос я хочу выяснить. Для получения воспроизводимых результатов я запускаю измерение во время реальной нагрузки, чтобы Горячие точки четко проявляться и не теряться в фоновом шуме.
Вот как я правильно читаю этот номер
В списке я сначала оцениваю Процентные значения по каждому символу, поскольку они отражают относительные доли времени. Высокие доли системных функций указывают на узкое место в ядре, тогда как доминирующие символы пользовательского пространства скорее указывают на логику приложения. Если я вижу много подпрограмм планировщика, я предполагаю, что это связано со слишком большим количеством активных потоков, неблагоприятными аффинностями или неподходящими приоритетами. Если в верхней части списка появляются функции памяти, я проверяю схемы выделения памяти, ошибки страниц, локальность NUMA и кэши. В случае сетевых путей я обращаю внимание на распределение IRQ, настройки Gro/TSO и поведение драйверов, поскольку такие детали Латентность оказывать значительное влияние.
Типичные причины возникновения «горячих точек» в ядре
Многие «горячие точки» возникают из-за того, что множество мелких расходов складывается в одну крупную Загрузить суммируются. Часто чрезмерные смены контекста, конкуренция за блокировку и неравномерное распределение IRQ приводят к увеличению времени процессора. Аналогичным образом, фрагментированные структуры памяти, неэффективное использование слабов или постоянная страничная организация памяти занимают ненужные циклы. Если я замечаю какой-то конкретный драйвер, я сопоставляю его с рабочей нагрузкой, аппаратным обеспечением и версией, чтобы сузить круг побочных эффектов. В многоядерных системах я также проверяю наличие ложного совместного использования (false sharing), поскольку, согласно документации ядра, общие строки кэша быстро приводят к дорогостоящему Накладные могут вызвать беспокойство.
Пример анализа «горячей точки»
Если в течение длительного периода времени в «Perf Top» я вижу высокую долю сетевых функций, я в первую очередь разделяю типы нагрузки: мелкие пакеты против крупных, TLS против открытого текста, большое количество соединений против небольшого числа длительных сеансов, чтобы определить Причина ограничить. Затем я углубляюсь в анализ с помощью perf record и perf report, включаю графики вызовов (-g) и сравниваю пути по результатам нескольких прогонов. Если же проблема связана с управлением памятью, я проверяю аллокатор, Huge Pages, настройки THP и NUMA-аффинность, поскольку в этом случае быстро возникают ненужные пути. «Горячие точки» планировщика я часто интерпретирую как признак слишком большого количества готовых к выполнению потоков или несоответствующей привязки к ЦП. Я всегда изменяю только один Параметры за каждый прогон, чтобы я мог точно соотнести результаты.
идеальное решение для хостинговых сред
В сценариях хостинга я часто замечаю, как небольшие затраты на ядро влияют на Латентность многих сервисов. Параллельно работающие контейнеры, виртуальные машины и экземпляры баз данных значительно смещают профиль в сторону сети, хранилища и планировщика. С помощью perf top я определяю, лежат ли узкие места скорее в обработке IRQ, обработке Softirq или в путях блокировок. Затем я учитываю в анализе версию ядра, расположение NUMA, аффинности IRQ и глубину очередей, поскольку эти факторы взаимодействуют между собой. Те, кто хочет углубиться в тему, найдут в этом руководстве по Анализ узких мест процессора еще несколько практических подходов, которые я регулярно использую в своей работе.
Практическое руководство по анализу
Я начну с воспроизводимого сценария нагрузки, чтобы результаты измерений оставались сопоставимыми, и Горячие точки стабильно появляются. Затем я запускаю perf top и фиксирую доминирующие символы в течение нескольких обновлений. Эту «моментальную фотографию» я обобщаю с помощью perf record/report, получая четкое представление о графах вызовов, чтобы определить путь к ресурсоемкому участку. Затем я целенаправленно изменяю только один параметр, например аффинность IRQ или глубину очереди, и провожу повторное измерение. Только когда эффект становится очевидным, я перехожу к следующему Шаг анализирую и документирую полученные данные для будущих периодов технического обслуживания.
Когда целесообразно использовать другие инструменты
Для анализа исторических данных, более детализированных графиков вызовов или конкретных цепочек событий я использую перфект record/report, ftrace или eBPF. Точки трассировки помогают мне целенаправленно анализировать пути, а программы BPF позволяют получать гибкие метрики. Если я хочу глубже изучить пути ядра, то Инструменты анализа eBPF ценные сигналы прямо на месте события. Для решения проблем с кэшированием и совместным использованием полезны инструменты perf-c2c и pahole, как только точка-горячка четко определена. Таким образом, я перехожу от анализа текущего состояния к выявлению причины, не увязая в несущественных подробности проиграть.
Параметры дискретизации и фильтры на практике
Я подхожу Выборка-Стратегия, ориентированная на конкретный вопрос, вместо того, чтобы измерять всё подряд. При спорадических всплесках я увеличиваю частоту выборки и сокращаю интервалы отображения, чтобы зафиксировать мимолетные пики. Для фокусировки на процессе я устанавливаю -p на соответствующий PID, для фокусировки на ЦП — -C на «горячие» ядра. С помощью -e я управляю событием, например cpu-cycles для широкого профилирования или cache-misses, если подозреваю проблемы с кэшем. Графики вызовов (-g) я использую, как только примерно локализую «горячую точку» и Причина хочет найти в стеке.
В приведенной ниже таблице представлены практичные комбинации клавиш, которые я часто использую в повседневной жизни, а также типичные области применения каждой опции:
| Вариант | Эффект | Используйте |
|---|---|---|
| -p PID | Ограничивает измерение одним процессом | Специфические для приложения Горячие точки ограничить |
| -C Список процессоров | Акцент на отдельные ядра | Проверить распределение NUMA/IRQ |
| -е Событие | Выберите аппаратное или программное событие | циклы, инструкции, промахи кэша |
| -g | Включить выборку Callgraph | Дорогие маршруты в Стек Узнайте |
| –kernel/–user | Фильтрует на уровне ядра или пользовательского пространства | Отделить источник времени процессора |
| –sort | Отсортировано по символу, DSO, dso:symbol | Читаемость Рейтинг увеличить |
Я всегда кратко тестирую конфигурации перед тем, как приступить к длительным измерениям, чтобы Показать остается стабильной и не возникает побочных эффектов. Особенно при высокой частоте дискретизации я обращаю внимание на накладные расходы, чтобы не создавать лишнюю нагрузку на систему. В случае с хостами контейнеров я дополнительно проверяю, не ограничивают ли обзор границы пространств имён и cgroup. Для обеспечения воспроизводимости результатов тестирования я документирую все параметры, включая версии ядра и драйверов. Такая дисциплина позже позволяет мне сэкономить много Время при классификации изменений.
Интерпретация подсистем: сеть, память, планировщик
Если в списке указаны сетевые пути, я сначала проверяю аффинности IRQ, RSS (Receive-Side-Scaling) и механизмы разгрузки, такие как GRO/TSO, поскольку эти настройки влияют на Пропускная способность-Изменение баланса задержек. При обнаружении подозрительных характеристик работы памяти я обращаю внимание на схемы выделения памяти, Huge Pages, статистику Slab и частоту ошибок доступа к страницам. Нагрузку на планировщик я часто связываю с чрезмерным количеством потоков, отсутствием аффинности к процессору или несправедливым распределением приоритетов. Для отслеживания конкретных событий ядра я дополнительно устанавливаю точки трассировки или использую bpftrace на хостинге, чтобы подтвердить гипотезы. Таким образом, я сопоставляю данные визуального наблюдения в режиме реального времени из «perf top» с данными более глубоких точек измерения и быстрее прихожу к самому Причина.
Требования и видимость символов
Так что perf top при преобразовании всех соответствующих символов ядра я обращаю внимание на две вещи: соответствующие права доступа и доступную информацию о символах. В рабочих системах kernel.perf_event_paranoid часто устанавливается на высокое значение. Для глубокого анализа ядра я временно уменьшаю это значение или работаю от имени пользователя root с необходимыми правами (CAP_PERFMON/CAP_SYS_ADMIN). Если адреса ядра замаскированы (kptr_restrict), я, как правило, всё равно вижу имена, но не сырые адреса — этого мне достаточно для расстановки приоритетов. Для пользовательского пространства я устанавливаю соответствующие пакеты с отладочной информацией, чтобы perf top показывал имена функций вместо смещений. Это позволяет избежать догадок и быстрее выявить причину.
Процентные показатели и подводные камни выборки
Я интерпретирую процентные показатели в списке как относительные доли измеренных выборок, а не как точную загрузку ЦП во временном диапазоне. Если выбрать несколько событий, то можно Мультиплексирование применяет: Perf распределяет контр-атаки во времени и нормализованный отображение. Чтобы получить четкую картину, я сначала измеряю общие показатели — циклы ЦП или количество инструкций — а специальные события включаю позже. Кратковременные всплески я фиксирую с помощью более высокой частоты (-F) и более коротких интервалов; для систем, работающих в спокойном режиме, достаточно стандартной частоты. Кроме того, я обращаю внимание на то, что Холостой ход-изменения фаз и частоты (Turbo, Governor) могут искажать результаты. Поэтому для сравнительных измерений я унифицирую настройки тактовой частоты и энергопотребления.
Подробное изучение графов вызовов
Как только я обнаруживаю «горячую точку», я повышаю информативность с помощью графов вызовов. С помощью -g и с помощью подходящего метода развертки я получаю путь к ресурсоемкому участку. Указатели фреймов или развертка DWARF обеспечивают мне стабильные стеки; там, где это возможно, я использую аппаратные буферы обратного вызова (LBR) для получения очень точных цепочек. Я увеличиваю буферы mmap только настолько, насколько это необходимо, чтобы свести накладные расходы к минимуму. Если в стеке присутствует много вспомогательных функций, я обращаю внимание на включая против. эксклюзивный Затраты: Решающим фактором является то, является ли сама функция дорогостоящей или она играет ведущую роль лишь в качестве транзитного участка. Это разграничение часто позволяет мне сэкономить несколько часов при поиске причин.
Работа в контейнерах и виртуальных машинах
В контейнерных средах я проверяю, верно ли отображается cgroups и пространства имён настроены правильно. Я сосредотачиваю измерения на соответствующих PID и процессорах, чтобы «шумные» соседи не искажали картину. Для виртуальных машин я проверяю, включен ли виртуальный PMU; в противном случае мне не хватает точных аппаратных событий, и я вижу в основном программные сигналы. Хосты KVM я часто распознаю по символам вокруг kvm_vcpu или vmx/svm. В таких ситуациях я четко разделяю анализ хоста и гостевой системы, чтобы не перепутать причину и следствие.
Узнаваемые закономерности и быстрые гипотезы
В повседневной жизни хорошо себя зарекомендовали определенные шаблоны, которые я сразу же проверяю:
- Конкуренция в Lock: Подводное плавание queued_spin_lock_slowpath или mutex_spin_on_owner В верхней части — структуры данных слишком грубо разбиты или рабочие очереди слишком узкие. Я снижаю уровень конкуренции за счет шардинга, более тонкой гранулярности блокировок или изменения размера пакетов.
- Печать из планировщика: Становятся все более частыми schedule(), pick_next_task_fair или пути пробуждения, я настраиваю количество потоков, аффинности и приоритеты. Часто достаточно просто “успокоить” «болтливые» потоки или чётко определить настройки ЦП.
- Сетевые SoftIRQ: Пиковые значения при net_rx_action, napi_poll или перенос расчета контрольной суммы указывают на пакетные штормы или неоптимальное распределение RSS и IRQ. Я назначаю IRQ соответствующим ядрам и настраиваю GRO/TSO для достижения желаемого профиля пропускной способности и задержки.
- Пути к хранилищам: Проводить много времени в do_page_fault, copy_user_* Или с помощью функций Slab я могу проверить схемы распределения памяти, THP/Huge Pages и локальность NUMA. Неправильное размещение здесь незаметно приводит к потере большого количества тактов.
- RCU и таймеры: Доминировать rcu_core или обратные вызовы таймера, я пересматриваю стратегии опроса и пакетной обработки в своих сервисах, чтобы обеспечить более плавную работу системы.
Углубить знания в области методологии измерений и воспроизводимости
Для обеспечения четкого сравнения результатов тестов я поддерживаю постоянные условия окружающей среды: режим управления ЦП, состояния Turbo, фоновые задания и даже температуру в помещении при плотной расстановке узлов. Я привязываю тестовые нагрузки к определённым ядрам и, при необходимости, изолирую «горячие» ЦП, чтобы решения планировщика оставались стабильными. Я документирую все изменения, включая версии ядра, драйверов и прошивки. При более рискованных настройках я заранее планирую точки отката и сразу после вмешательства провожу повторные измерения. Таким образом я получаю надёжные До/После-История, которую я могу понять даже спустя несколько месяцев.
Практические советы: команды, которые я часто использую
В зависимости от задачи я использую лаконичные формулировки:
- Широкий обзор при нагрузке: perf top -e cpu-cycles –kernel –user
Быстрый обзор того, кто здесь главный — ядро или пользовательское пространство. - Ориентация на процесс с помощью Callgraph: perf top -p PID -g –kernel –user
Покажите мне пути в реальном времени для соответствующего приложения без системных помех. - Внимание на процессор: perf top -C 2-5 -e cpu-cycles -g
Помогает при возникновении “горячих точек” NUMA или IRQ, когда «перегреваются» лишь несколько ядер. - Подозрение в хранении: perf top -e cache-misses -e cycles -g –kernel
Отображает пути к ячейкам памяти в соотношении с циклами. - Закрепить временные пики: perf top -F 999 -I 1000 -e циклов
Более высокая частота и более короткие интервалы отображения позволяют фиксировать кратковременные пики.
Рекомендации по интерпретации для конкретных подсистем
На сайте Сеть Помимо NAPI и траекторий RX/TX я также отслеживаю долю TLS/crypto, которая при высокой интенсивности рукопожатий может стать доминирующей. Я проверяю, эффективно ли работают механизмы Zero-Copy и коалесцирования, а также не превышают ли большие сегменты (TSO/GSO) мой бюджет задержки. В Память-В этой области я обращаю внимание на THP: помогает ли это моей нагрузке, или события Split/Merge создают помехи? При Хранение я понимаю blk_mq-символы и пути io_uring в качестве указания на глубину очереди и стратегии слияния. При планировщик Я связываю лавины Wakeup с цепочками Lock или IO и выравниваю задержки в путях с помощью обратного давления вместо “увеличения количества потоков”.
Пределы «perf top» и когда я меняю курс
Потому что perf top поскольку он основан на выборке, я лучше вижу средние значения, чем отдельные события. Для детерминированных цепочек выполнения я переключаюсь на точки трассировки (Tracepoints), ftrace или eBPF, чтобы точно подтвердить причинно-следственные связи. Если мне требуется точная количественная оценка (например, количество инструкций на запрос), я комбинирую это с perf stat или автономный анализ с помощью perf record/report. Если я сталкиваюсь с непонятными стеками (отсутствующие символы, некорректная развертка), сначала устраняю проблемы с видимостью — всё остальное было бы похоже на блуждание в тумане.
Краткое резюме
С perf top Я в режиме реального времени вижу, где процессор теряет время в ядре и какие символы следует изучить в первую очередь. На основании процентных показателей, повторяющихся паттернов и разделения ядра и пользовательского пространства я определяю целенаправленные дальнейшие действия. Затем я обобщаю полученные данные с помощью perf record/report, проверяю изменения под нагрузкой и документирую свою цепочку измерений. В хостинговых средах такой подход особенно оправдывает себя, поскольку многие сервисы и контейнеры получают взаимную выгоду, как только пути ядра начинают работать более эффективно. Тот, кто освоит этот процесс, сэкономит дни на диагностике и снизит Задержки и обеспечивает заметно более стабильное время отклика при реальной нагрузке.
