Человеческий мозг обычно лучше воспринимает информацию из изображений, чем из текстов. И в инструментах, подобных Flame Graph, этот принцип блестяще реализован. Поэтому в Percona его используют в рамках работы группы поддержки. Чаще всего в тех случаях, когда нужно получить всестороннее представление о том, что и как долго проделывает MySQL. Так можно лучше понять, какие операции стоят за конкретной рабочей нагрузкой и каким образом лучше исправлять возникающие проблемы. И это можно использовать и для оптимизации, и для устранения неполадок. Давайте воспользуемся их опытом и разберемся, откуда брать и как подготавливать образцы для визуализации данных. А после этого — как из них генерировать Flame Graph и как с этим работать. Рассмотрим два инструмента, с помощью которых можно получить данные для Flame Graphs. Они используются для создания графического представления функций, которые вызываются в выбранном нами программном обеспечении. В данном случае был выбран Percona Server для MySQL, но его можно распространить на любой софт для получения трассировки стека. Прежде чем мы начнем, прислушайтесь — НЕ запускайте его в производственных системах, если вы не разбираетесь в том, что делаете. Это относится к любым элементам профилирования. Начнем с perf (он же perf_events). Это интерфейс доступа к счетчикам в PMU (Performance Monitoring Unit), который является частью CPU. Для простоты в Percona используют команды для CentOS 7, для дистрибутивов на основе Debian все будет иметь тот же вид. Единственная разница в том, что вместо команды «yum» будет «apt-get install linux-tools-$(uname -r)». Чтобы установить perf, просто введите: Чтобы получить проект Flame Graphs: Вот и все! Можно приступать. Flame Graphs — это способ визуализации данных. Поэтому нужны образцы, из которых он будет строить графики. Получить их можно тремя способами. №1. Сбор только в течение установленного периода времени (в данном случае десять секунд): №2. Сбор до отправки сигнала прерывания (CTRL-C): В примерах 1,2 использовался флаг «-p», чтобы сбор данных производился только из интересующего нас процесса, но при необходимости можно собирать данные из всех запущенных процессов. №3. Сбор на протяжении всего жизненного цикла процесса: Так как невозможно заранее узнать ID процесса (PID), а при выполнении команды фактически запускается сервис MySQL, то данные мы собираем со всех процессов. Этот тип команды удобен, если вы хотите получить данные с самого начала процесса, что невозможно сделать другими способами. Обратите внимание, что прервав этот вариант, мы также прервем порожденный процесс, поэтому можно использовать еще и такой сбор: В этом варианте выполняется запрос к уже запущенному сервису MySQL, поэтому можно использовать флаг «-p» для сбора данных о серверном процессе. Это удобно, если вы хотите собрать данные о том, что происходит внутри MySQL в определенный момент. После первоначального сбора данных их еще нужно сделать «читабельными», потому что perf record хранит их в двоичном формате. Для этого можно использовать: Так, perf.data будет читаться по умолчанию. Но это имя файла уже использует perf record, поэтому его нужно переопределить с помощью флагов «-i» и «-o». После этого можно будет прочитать сгенерированный текстовый файл. Если вы его откроете, то увидите, что читать его довольно тяжело, именно поэтому мы агрегируем данные в более понятную визуальную форму. Для этого нужно перенаправить вывод stackcollapse-perf.pl на ввод flamegraph.pl. Поскольку мы не добавили папку git FlameGraph в наш путь, мы будем использовать полные пути: Теперь в любом браузере можно открыть файл .svg и начать анализ информационно-насыщенных графиков. Но сначала давайте рассмотрим весь код на примере: В пример вошли полные команды и их выходные данные. Чтобы избежать записи и чтения из выходного файла perf.script, пришлось объединить шаги №2 и №3 с помощью канала (|). Мы получили выходные данные по времени, поэтому можем увидеть оценку объема данных, которые генерирует инструмент: более 2 Мб за 1 минуту и 25 секунд. Данные, конечно, будут варьироваться в зависимости от многих факторов, поэтому их лучше протестировать в имеющейся среде. Еще давайте запустим запрос INSERT INTO … SELECT к базе данных, чтобы проанализировать его выполнение. Вот так выглядит скриншот Flame Graph, сгенерированный процессом по методу сбора данных №2: Его можно оптимизировать, покопавшись во write_record. Если сделать эту функцию быстрее, то мы получим большой потенциал для сокращения общего времени выполнения. В синей рамке в левом нижнем углу видно, что для построения графика взято в общей сложности более 60% выборок этого пути выполнения кода. Эта информация динамически меняется при наведении курсора на имена функций: В рамках интерпретации данных perf — это всё. Давайте теперь посмотрим еще один инструмент, который подходит для создания наглядных графиков. Flame Graphs изначально не задумывался для обработки выходных данных pt-pmp. Поскольку они аналогичны результату использования stackcollapse-perf.pl, то их тоже можно использовать, но с оговорками. Основные отличия выходных данных pt-pmp: В первом столбце указано количество потоков с обратной трассировкой. Имена функций разделяются запятой вместо точки с запятой. Pt-pmp печатает дату в первой строке, поэтому ее нужно будет обрезать. В этой части тоже есть свое «НО», на которое нужно обратить внимание. Pt-pmp будет использовать GDB в фоновом режиме, а значит, MySQL при сборе образцов остановится. Обязательно прочитайте документацию, прежде чем запускать всё это в производственной среде. Предположим, мы использовали простую команду pt-pmp: Чтобы компенсировать различия, описанные выше, мы можем использовать однострочник BASH, например: Эти команды приводят к следующим результатам: tail -n+2 pt-pmp.out  -> игнорирует первую строку, то есть дату; awk ‘{print $2, $1}’  -> перемещает количество потоков в конец строки так что backtrace оказывается вначале; sed -e ‘s/,/;/g’  -> меняет запятую на точку с запятой. После этого можно использовать perl-скрипт как обычно: Аргумент –countname предназначен только для изменения текста «образцов» по умолчанию, чтобы он лучше читался относительно количества потоков. Именно это означают числа в данном контексте. И тогда мы получаем требуемый svg-файл с Flame Graph, показывающий разные обратные трассировки и потоки: Кроме того, pt-stalk можно использовать не только для сбора типичной информации о метриках, связанных с ОС и MySQL, но и для сбора трассировки стека. Так у нас будет подробная информация о том, что происходит на сервере, и позволяющая провести улучшенный анализ. Подробнее о том, как собирать эти образцы, можно прочитать в онлайн-документации. Brendan Gregg – вдохновитель проекта Flame Graph) расскажет вам по теме еще больше GDB: Программа-отладчик для GNU Project Interpreting Flame Graphs Flame Graphs 201, отличный вебинар, чтобы лучше во всем разобраться Английская статья группы поддержки Percona по Flame Graph Flame Graph был создан, чтобы быстро и подробно понять использование ЦП при работе с MySQL. Но со временем область его применения расширилась, и он стал применяться для анализа и оптимизации различных операций под нагрузкой. По сравнению с длинными полотнами текстовых отчетов, а также трассировщиками, которые требуют большого опыта при интерпретации полученного результат, у Flame Graph есть явные преимущества. Его можно просматривать в любом браузере без каких-либо дополнительных инструментов, области будут кликабельными. Он интуитивно понятен и не требует длительного обучения. Источники: Profiling Software Using perf and Flame Graphs Using Flame Graphs to Process Outputs From pt-pm 27-28 июня в Москве впервые пройдет TestDriven Conf 2022 — профессиональная конференция для senior тестировщиков и  QA-инженеров.  Она будет посвящена всем вопросам автоматизации в   тестировании и рядом. Расписание и тезисы докладов уже на сайте. И можно купить или забронировать билеты по выгодной цене — чем ближе к конференции, тем будет дороже.