Perf linux ��� ���

Как установить и настроить Perf в дистрибутивах Linux

Мониторинг системы Linux обычен для каждого пользователя. Если вы системный администратор, возможно, вам придется тщательно проверить свою систему. Вы не можете найти много инструментов, чтобы узнать общее состояние системы; найти приложение, которое может генерировать подробную информацию о состоянии системы в реальном времени, сложно. Perf — это один из инструментов Linux, который вы можете использовать для получения подробной информации о проверке работоспособности и текущего положения в вашей системе. Perf — один из наиболее часто используемых и надежных инструментов системного мониторинга для сбора информации о ядре Linux, процессоре и оборудовании. Кроме того, он также может выполнять динамическую трассировку, проверять состояние оборудования и предоставлять отчеты о тестах производительности на машине Linux.

Инструмент мониторинга Perf в Linux

В Linux инструмент Perf может анализировать ядро, приложения, системные библиотеки, события программного обеспечения с помощью команд и подкоманд. Его также можно использовать как PMU (блок мониторинга производительности) в Linux. Инструмент Perf написан на языке программирования C и построен под лицензией GNU GL. В этом посте мы увидим, как установить инструмент Perf в системе Linux и как его запустить.

1. Установите Perf в Ubuntu/Debian Linux

Системный мониторинг Perf и инструмент анализа поставляются с общими для Linux пакетами. Установить Perf в дистрибутивы Ubuntu или Debian Linux довольно просто. Во-первых, вы можете начать с обновления системного репозитория.

Затем выполните следующую команду aptitude, приведенную ниже, чтобы установить общие инструменты Linux на свой компьютер. Следующая команда требует привилегий root; убедитесь, что вы являетесь пользователем root. Когда установка завершится, вы можете найти пакеты Perf в каталоге /usr/bin/perf.

Поскольку Perf — это общий пакет Linux, убедитесь, что Perf совместим с вашим ядром Linux. Чтобы проверить ядро ​​вашей системы, выполните следующую команду. Взамен вы получите версию своего ядра.

Теперь запишите версию своего ядра и напишите команду терминала, показанную ниже, для установки общих инструментов Linux, подходящих для вашего ядра.

Теперь вы можете, наконец, запустить следующую команду, чтобы проверить версию Perf на вашем компьютере. В свою очередь, вы увидите, что Perf имеет ту же версию, что и ядро.

2. Установка Perf в Fedora/Red Hat

Установить инструмент мониторинга системы Perf на Red Hat Linux или рабочую станцию ​​Fedora проще, чем на Debian/Ubuntu. Вы можете запустить следующие команды YUM в оболочке терминала на вашем компьютере, установив инструмент Perf. Следующие команды требуют привилегий root; убедитесь, что он у вас есть.

Если вы используете машину Red Hat на основе DNF, вы можете попробовать выполнить следующие команды в Perf установки оболочки.

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

3. Начните с Perf

До сих пор мы видели, как установить Perf в Ubuntu и в системе Red Hat/Fedora. Пора начать с этого. Вначале вы можете запустить команду help , чтобы познакомиться с синтаксисами Perf.

Здесь я покажу несколько важных и повседневных команд Perf. Для всех команд требуются привилегии root, и они выполняются во всех дистрибутивах Linux. Если вы видите сообщение об ошибке, как показано ниже, нет причин для беспокойства. Вам просто нужно вернуться в командную оболочку и повторно запустить команду с правами root.

1. ls -ld

Команды ls -ld могут выводить на печать состояние использования ЦП, циклы ЦП и другую статистику счетчиков производительности, связанных с ЦП.

2. list

В Linux инструмент Perf может распечатать все события ядра с помощью команды list. Он может создавать как подробные, так и статистические отчеты о событиях ядра.

3. top

Следующая команда top может очень точно распечатать события тактовой частоты процессора и события ядра. Он также показывает процент использования ядра и процессора.

4. record

Следующая команда запишет данные любой команды Perf, которую вы хотите сохранить для использования в будущем.

Чтобы просмотреть или отобразить записанные данные, вы можете запустить следующую команду report в оболочке.

5. bench

Чтобы запустить быстрый тест производительности вашей системы, вы можете выполнить следующую команду, чтобы получить отчеты о тестировании производительности системы, тактовой частоты процессора и других параметров.

Дополнительный совет: если вы не можете найти Perf для своего ядра

Если вы используете бета-версию ядра или настраиваемое ядро ​​в своей системе Linux, есть вероятность, что вы можете использовать Perf для своей системы. В этом случае вы можете обновить текущую версию ядра до стабильной версии, которая может запускать Perf. Вы можете проверить список ядер, которые работают с Perf .

Заключительные слова

Используя инструмент Perf в системе Linux, можно создать подробный список статистики процессора и ядра. Во всем посте я описал метод установки инструмента Perf в системах Linux на базе Ubuntu и Red Hat. Позже я показал несколько основных команд Perf, чтобы начать с ним работать.

Пожалуйста, поделитесь им со своими друзьями и сообществом Linux, если вы найдете этот пост полезным и информативным. Вы сообщаете нам, какую версию инструментов вы используете в настоящее время в своей системе для отслеживания системной статистики. Напишите свое мнение об этом сообщении в разделе комментариев.

Источник

Main Page

Contents

perf: Linux profiling with performance counters

. More than just counters.

Introduction

This is the wiki page for the Linux perf command, also called perf_events. perf is powerful: it can instrument CPU performance counters, tracepoints, kprobes, and uprobes (dynamic tracing). It is capable of lightweight profiling. It is also included in the Linux kernel, under tools/perf, and is frequently updated and enhanced.

perf began as a tool for using the performance counters subsystem in Linux, and has had various enhancements to add tracing capabilities.

Performance counters are CPU hardware registers that count hardware events such as instructions executed, cache-misses suffered, or branches mispredicted. They form a basis for profiling applications to trace dynamic control flow and identify hotspots. perf provides rich generalized abstractions over hardware specific capabilities. Among others, it provides per task, per CPU and per-workload counters, sampling on top of these and source code event annotation.

Tracepoints are instrumentation points placed at logical locations in code, such as for system calls, TCP/IP events, file system operations, etc. These have negligible overhead when not in use, and can be enabled by the perf command to collect information including timestamps and stack traces. perf can also dynamically create tracepoints using the kprobes and uprobes frameworks, for kernel and userspace dynamic tracing. The possibilities with these are endless.

The userspace perf command present a simple to use interface with commands like:

• perf stat: obtain event counts
• perf record: record events for later reporting
• perf report: break down events by process, function, etc.
• perf annotate: annotate assembly or source code with event counts
• perf top: see live event count
• perf bench: run different kernel microbenchmarks

To learn more, see the examples in the Tutorial.

Источник

Perf и flamegraphs

Огромную популярность набирает тема повышения производительности операционных систем и поиска узких мест. В этой статье мы расскажем об одном инструменте для поиска этих самых мест на примере работы блочного стека в Linux и одного случая траблшутинга работы хоста.

Пример 1. Тестовый

Ничего не работает

Тестирование в нашем отделе ― это синтетика на продуктовом железе, а позже ― тесты прикладного ПО. К нам на тестирование поступил диск Intel Optane. Ранее о тестировании дисков Optane мы уже писали в нашем блоге.

Диск был установлен в сервер стандартной комплектации, собранный относительно давно под один из облачных проектов.

Во время тестирования диск показал себя не лучшим образом: при тесте с глубиной очереди в 1 запрос в 1 поток, блоками в 4Кбайта около

70Kiops. А это значит, что время ожидания ответа огромно: примерно 13 микросекунд на запрос!

Странно, ведь спецификация обещает “Latency ― Read 10 µs”, а у нас получилось на 30% больше, разница довольно существенная. Диск переставили в другую платформу, более «свежей» сборки, используемую в другом проекте.

Почему оно работает?

9 микросекунд на запрос.

И тут самое время сравнить настройки достать из широких штанин perf. Ведь нам интересно, почему так? При помощи perf можно:

• Снимать показатели аппаратных счетчиков: количество вызовов инструкций, кэш-промахов, неверно предсказанных ветвлений и т.п. (PMU events)
• Снимать информацию со статических трейспоинтов, количество вхождений
• Проводить динамическую трассировку

Для проверки мы воспользовались CPU sampling.

Суть в том, что perf может собрать весь стэк трейс запущенной программы. Естественно, запущенный perf будет вносить задержку в работу всей системы. Но у нас есть флаг -F #, где # ― частота сэмплирования, измеряемая в Гц.

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

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

Ещё один момент, который поначалу вводит в заблуждение ― ПО должно быть собрано с флагом -fno-omit-frame-pointer, если это, конечно, возможно. Иначе в трейсе вместо названий функций мы увидим сплошные значения unknown. Для некоторого ПО отладочные символы идут отдельным пакетом, например, someutil-dbg. Рекомендуется установить их перед запуском perf.

Нами были выполнены следующие действия:

• Взят fio из git://git.kernel.dk/fio.git, тэг fio-3.9
• В Makefile к CPPFLAGS добавлена опция -fno-omit-frame-pointer
• Запущен make -j8

Опция -g нужна для захвата стек трейсов.

Посмотреть полученный результат можно командой:

Опция -g fractal нужна для того, чтобы проценты, отражающие количество сэмплов с этой функцией и показываемые perf, были относительны вызывающей функции, количество вызовов которой берется за 100%.

Ближе к концу длинного стека вызовов fio на платформе «свежей сборки» мы увидим:

А на платформе “старой сборки”:

Отлично! Но хочется красивых флеймграфов.

Построение флеймграфов

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

• Относительно более статический flamegraph
• Flamescope, который дает возможность из собранных сэмплов выбрать конкретный отрезок времени. Это очень полезно, когда искомый код нагружает CPU короткими всплесками

Эти утилиты принимают на вход вывод perf script > result.

Скачиваем result и отправляем его через пайпы в svg:

Открываем в браузере и наслаждаемся кликабельной картинкой.

Можно использовать другой способ:

1. Добавляем result в flamescope/example/
2. Запускаем python ./run.py
3. Заходим через браузер на 5000 порт локального хоста

Что мы видим в итоге?

Хороший fio проводит много времени в поллинге:

А плохой fio проводит время где угодно, но только не в поллинге:

С первого взгляда кажется, что на старом хосте не работает поллинг, но везде стоит ядро 4.15 одной сборки и поллинг по умолчанию включен на NVMe-дисках. Проверить, включен ли поллинг, можно в sysfs:

Во время тестов используются вызовы preadv2 с флагом RWF_HIPRI ― необходимое условие для работы поллинга. И, если внимательно изучить флеймграф (или предыдущий скриншот из вывода perf report), то его можно найти, но он занимает совсем незначительный промежуток времени.

Второе, что видно ― это отличающийся стек вызовов у функции submit_bio() и отсутствие вызовов io_schedule(). Посмотрим поближе на разницу внутри submit_bio().

Медленная платформа «старой сборки»:

Быстрая платформа «свежей»:

Похоже, что на медленной платформе запрос проходит долгий путь до устройства, заодно попадая в планировщик kyber. О планировщиках ввода/вывода подробнее можно прочитать в нашей статье.

Как только kyber был выключен, тот же тест fio показал среднее время ожидания около 10 микросекунд, прямо как заявлено в спецификации. Отлично!

Но откуда разница еще в одну микросекунду?

А если чуть глубже?

Как уже было сказано, perf позволяет собирать статистику с аппаратных счетчиков. Попробуем посмотреть количество кэш-промахов и инструкций на цикл:

Из результатов видно, что быстрая платформа выполняет больше инструкций на цикл CPU и имеет меньший процент кэш-промахов при выполнении. Вдаваться в детали работы разных аппаратных платформ в рамках этой статьи мы, конечно, не будем.

Пример 2. Продуктовый

Что-то идет не так

В работе распределенной системы хранения данных был замечен рост нагрузки на CPU на одном из хостов при росте входящего трафика. Хосты равноправные, равнозначные и имеют идентичные аппаратное и программное обеспечение.

Рассмотрим как выглядит нагрузка на CPU:

Проблема возникла в 09:23:46 и мы видим, что процесс работал в пространстве ядра исключительно в течении всей секунды. Посмотрим на то, что происходило внутри.

Почему так медленно?

В данном случае мы сняли сэмплы со всей системы:

Опция -a нужно здесь для того, чтобы perf снимал трейсы со всех CPU.

Откроем perf.results при помощи flamescope, чтобы отследить момент повышенной нагрузки на CPU.

Перед нами «тепловая карта», обе оси (X и Y) которой представляют собой время.

По оси X пространство разбито на секунды, а по оси Y ― на отрезки по 20 миллисекунд в пределах секунд X. Время идет снизу вверх и слева направо. Наиболее яркие квадраты имеют наибольшее количество сэмплов. То есть, CPU в это время работал активнее всего.

Собственно, нас интересует красное пятно посередине. Выделяем его мышкой, кликаем и смотрим, что оно скрывает:

В целом, уже видно, что проблема заключается в медленной работе tcp_recvmsg и skb_copy_datagram_iovec в ней.

Для наглядности сравним с сэмплами другого хоста, на котором тот же объем входящего трафика не вызывает проблем:

Исходя из того, что мы имеем одинаковое количество входящего трафика, идентичные платформы, которые работают уже длительное время без остановки, можно предположить, что проблемы возникли на стороне железа. Функция skb_copy_datagram_iovec копирует данные из структуры ядра в структуру в пространстве пользователя, чтобы передать дальше приложению. Вероятно, имеются проблемы с памятью хоста. При этом, в логах ошибок нет.

Перезапускаем платформу. При загрузке BIOS видим сообщение о битой планке памяти. Замена, хост стартует и проблема с перегруженным CPU больше не воспроизводится.

Постскриптум

Производительность системы с perf

Вообще говоря, на загруженной системе запуск perf может внести задержку в обработку запросов. Размер этих задержек зависит в том числе и от нагрузки на сервер.

Попробуем найти эту задержку:

Разница не сильно заметна, всего около

Посмотрим, что будет, если увеличить нагрузку:

Здесь разница уже становится заметна. Можно сказать, что система замедлилась менее чем на 1%, но по существу потеря около 7Kiops на высоконагруженной системе может привести к проблемам.

Понятно, что данный пример синтетический, тем не менее он весьма показательный.

Попробуем запустить еще один синтетический тест, который вычисляет простые числа ― sysbench:

Здесь видно, что даже минимальное время обработки увеличилось на 270 микросекунд.

Вместо заключения

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

Источник