Профилировщик запросов
Порядок установки модулей и расширений описан в разделе «Установка дополнительных элементов».
Модуль Query Profiler предназначен для профилирования запросов. Работа модуля основана на сборе статистики из расширения pg_stat_statements. Все данные из pg_stat_statements группируются особым образом, чтобы исключить дублирование для идентичных запросов.
Чтобы открыть эту страницу, нажмите на «Профилировщик запросов» в левой панели меню экземпляра.
На каждой итерации сбора статистической информации делается выборка только 50 самых длительных запросов, все остальные группируются в блок other.
Рассмотрим функционал модуля, согласно нумерации, обозначенной на рисунке выше:
График отображает среднее время выполнения запросов. Выпадающий список в правом верхнем углу дает возможность выбрать временной интервал, за который необходимо показать информацию. Выбранный интервал времени также влияет на список запросов ниже. Доступно семь временных интервалов:
последние 30 минут (по умолчанию),
последний час,
последние 3 часа,
последние 8 часов,
последние 12 часов,
последний день,
последние 7 дней.
Также можно выбрать дату, от которой будет отсчитан интервал.
Поиск по хэшу запроса.
Сортировка запросов:
Top total time (default) — общее время (по умолчанию);
Top returned rows — количество возвращенных строк;
Top CPU Time — время ЦП;
Top IO Time — время ввода-вывода;
Top calls — количество вызовов;
Top temp blocks written — количество блоков, записанных во временном хранилище.
Фильтр, позволяющий выполнить фильтрацию по базам данных.
Символ «+» открывает подстроку, чтобы увидеть сам запрос.
Запрос можно скопировать в буфер обмена с помощью кнопки, обозначенной цифрой 1 на рисунке выше.
Меню с опцией «Подробнее» для детального рассмотрения запроса.
Для просмотра детальной информации кликните на строку запроса или выберите в контекстном меню «Подробнее».
Вкладка «Статистика»
После перехода к детальной информации по запросу откроется вкладка «Статистика».
Рассмотрим вкладку подробнее, согласно нумерации, обозначенной на рисунке выше:
График отображает данные за определенный временной интервал. Вы можете выбрать один из семи вариантов временного интервала:
последние 30 минут (по умолчанию),
последний час,
последние 3 часа,
последние 8 часов,
последние 12 часов,
последний день,
последняя неделя.
Также можно выбрать дату, от которой будет отсчитан интересующий интервал.
Можно просмотреть шесть графиков. Чтобы переключиться между ними, нажмите на точки.
Time Query/Second,
Calls/Second,
Rows/Second,
CPU Time/ Second,
IO Time/Second,
Dirtied Blocks/Second,
Temp Blocks(Write)/Second.
Текст запроса можно скопировать в буфер обмена.
Вкладка «Планы»
Для работы с планами запросов установите расширение pg_store_plans. Инструкция по установке находится на странице «Установка и настройка расширения pg_store_plans».
Данные об использовании планов запросов представлены в формате гистограмм. Каждый план отображается уникальным цветом. Высота столбца в гистограмме по каждому из планов зависит от количества вызовов данного плана.
Рассмотрим вкладку подробнее, согласно нумерации, обозначенной на рисунке выше:
Вы можете выбрать один из семи вариантов временного интервала:
последние 30 минут (по умолчанию),
последний час,
последние 3 часа,
последние 8 часов,
последние 12 часов,
последний день,
последняя неделя.
Также можно выбрать дату, от которой будет отсчитан интересующий интервал.
Символ «+» открывает план выполнения, используемый для выбранного запроса.
План выполнения можно скопировать в буфер.
Анализатор планов запросов
Анализатор планов запросов интегрирован в платформу Tantor на основе сервиса https://explain.tensor.ru. Эта интеграция позволяет пользователю проводить анализ запросов и логов базы данных в рамках платформы Tantor и не требует отправки запросов и данных, находящихся в них, во внешние сервисы. Более того, платформа Tantor собирает и хранит запросы в соответствии с установленной конфигурацией, существенно облегчая поиск запросов по таким параметрам, как время запроса, количество строк и многое другое.
Конфигурация
Для корректной работы установите следующие расширения:
pg_stat_statements, который поставляется в каталоге contrib дистрибутива PostgreSQL и Tantor DB всех версий;
pg_store_plans сборки Tantor (отличается от находящегося в общем доступе).
Методы доступа
Существует три метода доступа к анализатору планов запросов.
Доступ из верхнего меню:
При нажатии на доступ из верхнего меню расширение откроется в новой вкладке и не будет содержать запросов, находящихся в платформе. Этот функционал позволяет скопировать в новое окно любой запрос для проведения анализа:
Доступ из экрана «Обзор» экземпляра через запрос «5 самых длительных запросов».
Этот метод позволяет проанализировать запрос, который попал в TOP 5.
внизу плашки «5 самых длительных запросов» нажмите на текст интересующего запроса;
в открывшемся меню нажмите на «Подробнее»:
в открывшемся меню перейдите на вкладку «Планы»:
В результате откроется окно с анализом:
Доступ через экран Queries.
Этот метод позволяет проанализировать запрос, который попал в Top 50 запросов, которые собирает и анализирует платформа. Чтобы открыть анализатор запросов, выполните следующие действия:
нажмите на «Профилировщик запросов»:
нажмите на нужный запрос:
откроется страница со статистикой по запросу:
перейдите на вкладку «Планы»:
на открывшейся странице нажмите на интересующий вас план (цифра 2 на рисунке выше). Откроется страница с анализом плана:
Основные компоненты
Навигатор [1]
Позволяет оценить с помощью полоски-навигатора, сколько времени занял каждый узел. При нажатии на него произойдет переход на нужный узел:
Если доминируют красные сегменты — вы тратите много времени на чтение данных (Seq Scan, Index Scan, Bitmap Heap Scan), если желтые — на их обработку (Aggregate, Unique), а зеленых Join должно быть не слишком много.
Average IO [1]
Если в вашем плане присутствуют показатели времени, затраченного на операции ввода-вывода (атрибут I/O Timings при включенном параметре track_io_timing), то теперь в строке итогов можно мгновенно оценить усредненные показатели скорости доступа к диску при последовательном и случайном чтении или записи:
Предупреждение
Если вы видите тут цифры в единицы MB/s, хотя база находится на SSD, то где-то в работе дисковой подсистемы явно есть проблема.
Дерево rows/RRbF [1]
На tilemap-диаграмме плана режим rows позволяет мгновенно оценить, в каком сегменте плана генерируется или фильтруется чересчур много записей.
В этом режиме подсвечиваются те узлы, на которых из-за несоответствия условию (Rows Removed by …) было отброшено наибольшее количество записей. «Ширина» связи пропорциональна количеству записей, которые были переданы вверх по дереву.
Чем ярче узел и толще его «ветви», тем больше внимания на него нужно обратить:
Тултип узла [1] [2]
Наводя курсор на узел в навигаторе или любой другой диаграмме, вы сразу видите все иконки рекомендаций, которые советует сервис:
Если это подсказка об индексе, то простого клика по ней достаточно, чтобы перейти к предлагаемым вариантам подходящих индексов.
Также для всех больших чисел в тексте узла добавлены разделители разрядов, чтобы сходу воспринимать порядок величин.
Круговая диаграмма [2]
Понять «где болит сильнее всего» непросто, особенно, если запрос содержит несколько десятков узлов, и даже сокращенная форма плана занимает 2-3 экрана. В этом случае на помощь придет круговая диаграмма:
Сразу, навскидку, видна примерная доля потребления ресурсов каждым из узлов. При наведении на него слева в текстовом представлении отображается иконка у выбранного узла.
Диаграмма выполнения [2]
Тултип узла и круговая диаграмма не показывают полную цепочку вложений служебных узлов CTE/InitPlain/SubPlan — его можно увидеть только на диаграмме реального выполнения:
Источник