Чтение flame graph: ширина — это сэмплы, а ось x — не время

Цель

Правильно читая flame graph, найти, на что работающая программа тратит процессорное время, вместо просмотра плоского списка функций и догадок о вызывающем коде.

Предварительные условия

Сэмплирующий профилировщик, записывающий стеки вызовов (Linux perf, py-spy для Python, собственный сэмплер среды выполнения), скрипты FlameGraph или профилировщик, сразу создающий SVG, символы и информация для развёртывания стека, чтобы кадры не отображались как [unknown], а также репрезентативная нагрузка во время сбора сэмплов.

Шаги

1. Собирайте профиль под нагрузкой. Пример Грегга: perf record -F 99 -p PID -g -- sleep 30, затем perf script | stackcollapse-perf.pl > out.folded и flamegraph.pl out.folded > out.svg; нечётные частоты, например 99 Гц, позволяют избежать синхронизации сэмплирования с другой активностью. Для Python py-spy record -o profile.svg --pid 12345 сразу записывает диаграмму.
2. Читайте оси по определению на странице flame graph: ось x — набор профилированных стеков, отсортированный по алфавиту, а не течение времени; ось y — глубина стека, начиная с нуля внизу. Каждый прямоугольник — кадр; чем он шире, тем чаще встречался в сэмплах. Верхняя кромка показывает то, что исполнялось на CPU, а всё под ней — цепочку предшествующих вызовов.
3. Ищите широкие плато вдоль верхней кромки: эти функции исполнялись сами и являются кандидатами на более быстрые реализации.
4. Ищите ниже широкие кадры, чьи потомки образуют множество узких башен: время распределено между вызываемыми функциями, поэтому менять нужно вызывающую сторону (вызывать реже, объединять в пакеты, кэшировать).
5. Используйте поиск в SVG, чтобы суммировать ширину функции по всем стекам; функция, вызываемая из многих мест, выглядит как узкие башни, которые нужно сложить.
6. Сравнивайте два профиля (до и после изменения либо с медленного и исправного узла) с помощью дифференциального flame graph, который окрашивает каждый кадр по изменению между профилями.
7. Прежде чем доверять малой ширине, проверьте число сэмплов: тридцать секунд при 99 Гц дают около 2970 сэмплов на CPU (арифметический расчёт), поэтому кадр шириной 1% опирается примерно на 30 сэмплов, а доли процента — это шум.
8. Если программа медленная, но CPU простаивает, CPU flame graph не покажет ничего полезного; вместо него снимите off-CPU-профиль ожидания.

Ожидаемый результат

Конкретная функция или путь вызовов с долей сэмплов, профиль, сохранённый рядом с устраняющим проблему изменением, и второй профиль, показывающий уменьшение ширины.

Ограничения и основания метода

Отсутствие указателей кадров или агрессивный инлайнинг обрезают либо объединяют кадры. Сэмплирование относит время к исполнявшейся инструкции, а не к его причине; промах кэша отображается как инструкция, которая остановилась в ожидании. Интерпретируемым и JIT-компилируемым языкам нужны собственные средства обхода стека. Материал основан на указанных страницах; результаты измерений не заявляются.