Русский
Русский
English
Статистика
Реклама

Вооруженным глазом наглядно о проблемах PostgreSQL-запроса

Продолжаем открывать для публичного доступа новый фукционал нашего сервиса анализа планов выполнения запросов в PostgreSQL explain.tensor.ru. Сегодня мы научимся определять больные места навскидку в больших и сложных планах, лишь мельком взглянув на них вооруженным глазом


В этом нам помогут различные варианты визуализации:



Сокращенный текстовый вид


Оригинальный текст достаточно несложного плана уже вызывает проблемы при анализе:



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



Круговая диаграмма


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



В этом случае на помощь придет обычная круговая диаграмма:



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

Плитка


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



Диаграмма выполнения


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



Нужно больше метрик!


Если вы снимаете план реального выполнения запроса как EXPLAIN (ANALYZE), то увидите там только затраченное время. Но очень часто этого недостаточно для правильных выводов!

Например, выполняя запрос на непрогретом кэше вы получите (но не увидите!) время получения данных с носителя, а вовсе не работы самого запроса.

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

  • Используйте EXPLAIN (ANALYZE, BUFFERS), чтобы увидеть объем вычитываемых страниц данных. Эта величина практически не подвержена колебаниям от нагрузки самого сервера и может быть использована в качестве метрики при оптимизации.
  • Используйте track_io_timing, чтобы понимать, сколько именно времени заняла работа с носителем.

И вот если ваш план содержит не только время, но и buffers или i/o timings, то на каждой из вариантов диаграмм вы сможете переключиться в режим анализа этих метрик. Иногда можно сразу увидеть, например, что больше половины всех чтений пришлось на единственный проблемный узел:



Предыдущие статьи по теме:

Источник: habr.com
К списку статей
Опубликовано: 29.07.2020 22:04:59
0

Сейчас читают

Комментариев (0)
Имя
Электронная почта

Блог компании тензор

Postgresql

Sql

Администрирование баз данных

Визуализация данных

Explain

Explain.tensor.ru

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru