Профайлер запросов (Query Profiler)

Порядок установки модулей, расширений см. в разделе Установка дополнительных элементов.

Модуль Query Profiler предназначен для профилирования запросов. Работа данного модуля основана на сборе статистики из расширения pg_stat_statements. Все данные из pg_stat_statements группируются особым образом, чтобы исключить дублирование для идентичных запросов.

На каждой итерации сбора статистической информации делается выборка только 50 самых длительных запросов, все остальные группируются в блок other. Рассмотрим функционал модуля, согласно нумерации, обозначенной на рисунке ниже:

../_images/query_image3.jpg
  • График (цифра 1 на рисунке выше) отображает среднее время выполнения запросов. Выпадающий список в правом верхнем углу дает возможность выбрать временной интервал, за который необходимо показать информацию. Выбранный интервал времени, кроме того, влияет на список запросов ниже. Временной интервал имеет семь вариантов на выбор:

    • последние 30 минут (по умолчанию),

    • последний час,

    • последние 3 часа,

    • последние 8 часов,

    • последние 12 часов,

    • последний день и последняя неделя.

  • Поиск по хэшу запроса (цифра 2 на рисунке выше).

  • Сортировка запросов(цифра 3 на рисунке выше):

    • Total Time - общее время(по умолчанию),

    • Rows - количество возвращенных строк,

    • CPU Time - время ЦП,

    • IO Time - время ввода-вывода

    • Calls - количество вызовов.

  • Фильтр, позволяющий выполнить фильтрацию по базам данных (цифра 4 на рисунке выше).

  • Меню с опциями для более детального рассмотрения запроса (цифра 5 на рисунке выше).

  • Символ “+” - открывает подстроку(рисунок ниже) для того, чтобы увидеть сам запрос (цифра 6 на рисунке выше).

../_images/query_image6.jpg

Скопировать запрос в буфер (номер 1).

Для просмотра более детальной информации по запросу необходимо кликнуть на строку или выбрать в контекстном меню “Details”:

Statistics

../_images/query_image4.jpg

Рассмотрим приведенную выше страницу в соответствии с предоставленной нумерацией:

График имеет возможность отображать данные за определенный временной интервал(номер 1). Вы можете выбрать один из семи вариантов временного интервала:

  • последние 30 минут (по умолчанию),

  • последний час,

  • последние 3 часа,

  • последние 8 часов,

  • последние 12 часов,

  • последний день,

  • последняя неделя.

Для вашего удобства есть шесть различных графиков. Вы можете переключаться между ними, нажимая на точки (цифра 2):

  • Time Query/Second

  • Calls/Second

  • Rows/Second

  • CPU Time/ Second

  • IO Time/Second

  • Dirtied Blocks/Second

Скопировать запрос в буфер (номер 3).

Plans

Для работы с планами запросов, необходимо установить расширение pg_store_plans (см. подпункт Установка и настройка расширения pg_store_plans).

../_images/query_image1.jpg

Данные об использовании планов запросов представлены в формате гистограмм. Каждый план отображается уникальным цветом. Высота столбца в гистограмме по каждому из планов зависит от количества вызовов данного плана.

Рассмотрим приведенный выше скриншот в соответствии с предоставленной нумерацией. Вы можете выбрать один из семи вариантов временного интервала(номер 1):

  • последние 30 минут (по умолчанию),

  • последний час,

  • последние 3 часа,

  • последние 8 часов,

  • последние 12 часов,

  • последний день,

  • последняя неделя.

При нажатии на символ “+” (цифра 2) вы можете увидеть план выполнения, используемый для выбранного запроса.

../_images/query_image2.jpg

Скопировать план выполнения в буфер (номер 1).

Анализатор планов запросов

Анализатор планов запросов интегрирован в платформу Tantor на основе сервиса https://explain.tensor.ru. Данная интеграция позволяет пользователю проводить анализ запросов и логов базы данных в рамках платформы Tantor и не требует отправки запросов и данных, находящихся в них во внешние сервисы. Более того, платформа Tantor собирает и хранит запросы в соответствии с установленной конфигурацией, существенно облегчая поиск запросов по таким параметрам, как время запроса, количество строк и многое другое.

Конфигурация

Для корректной работы необходимо установить следующие расширения:

  • pg_stat_statements, который поставляется в каталоге contrib дистрибутива PostgreSQL и Tantor DB всех версий;

  • pg_store_plans сборки Tantor (отличается от находящегося в общем доступе).

Методы доступа

Существует три метода доступа к ализатору планов запросов.

Метод 1: Доступ из верхнего меню:

../_images/image14.png

При нажатии на доступ из верхнего меню расширение откроется в новой вкладке и не будет содержать запросов, находящихся в платформе. Этот функционал позволяет скопировать в новое окно любой запрос для проведения анализа:

../_images/image2.png

Метод 2: Доступ из экрана “Overview” через запрос TOP 5.

Данный метод позволяет проанализировать запрос, который попал в TOP 5, для доступа следует:

  • нажать внизу плашки TOP 5 на текст интересующего запроса. Откроется меню;

  • в открывшемся меню нажать на details:

../_images/image3.png

Откроется окно;

  • в открывшемся меню нажать на plans:

../_images/image43.png

В результате откроется окно с анализом:

../_images/image51.png

Метод 3: Доступ через экран Queries.

Данный метод позволяет проанализировать запрос, который попал в Top 50 запросов, которые собирает и анализирует платформа. Для доступа следует:

  • нажать на Query Profiler:

../_images/image65.png
  • нажать на интересующий запрос:

../_images/image74.png
  • в открывшемся окне нажать на строку интересующего плана:

../_images/image8.png

В результате откроется окно с анализом:

../_images/image91.png

Основные компоненты

Навигатор [1]

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

../_images/image103.png

Если доминируют красные сегменты - вы тратите много времени на чтение данных (Seq Scan, Index Scan, Bitmap Heap Scan, …), если желтые - на их обработку (Aggregate, Unique, …), а зеленых Join должно быть не слишком много.

Average IO [1]

Если в вашем плане присутствуют показатели времени, затраченного на операции ввода-вывода (атрибут I/O Timings при включенном параметре track_io_timing), то теперь в строке итогов можно мгновенно оценить усредненные показатели скорости доступа к диску при последовательном и случайном чтении или записи:

../_images/image115.png

Предупреждение

Если вы видите тут цифры в единицы MB/s, хотя база находится на SSD, то где-то в работе дисковой подсистемы явно есть проблема.

Дерево rows/RRbF [1]

На tilemap-диаграмме плана режим rows - в нем вы можете мгновенно оценить, в каком сегменте плана генерируется или фильтруется чересчур много записей.

В этом режиме подсвечиваются те узлы, на которых было отброшено из-за несоответствия условию (Rows Removed by …) наибольшее количество записей, а «ширина» связи пропорциональна количеству записей, которые были переданы вверх по дереву.

Чем ярче узел и толще его «ветви», тем более пристально стоит к нему присмотреться:

../_images/image121.png
Тултип узла [1] [2]

Наводя курсор на узел в навигаторе или любой другой диаграмме, вы сразу видите все иконки рекомендаций, которые советует наш сервис:

../_images/image139.png

Если это подсказка об индексе, то простого клика по ней достаточно, чтобы перейти к предлагаемым вариантам подходящих индексов.

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

../_images/image147.png
Круговая диаграмма [2]
Понять «где болит сильнее всего» непросто, особенно если запрос содержит несколько

десятков узлов, и даже сокращенная форма плана занимает 2-3 экрана. В этом случае на помощь придет круговая диаграмма:

../_images/image147.png

Сразу, навскидку, видна примерная доля потребления ресурсов каждым из узлов. При наведении на него, слева в текстовом представлении мы увидим иконку у выбранного узла.

Плитка [1]

Круговая диаграмма плохо показывает отношения между разными узлами и «самые горячие» точки. Для этого гораздо лучше подойдет вариант отображения «плиткой»:

../_images/image152.png
Диаграмма выполнения [2]

Оба предыдущих варианта не показывают полную цепочку вложений служебных узлов CTE/InitPlain/SubPlan — его можно увидеть только на диаграмме реального выполнения:

../_images/image161.png

Источник