[PostgreSQL, SQL, Администрирование баз данных, Визуализация данных] Вооруженным глазом: наглядно о проблемах PostgreSQL-запроса
Автор
Сообщение
news_bot ®
Стаж: 6 лет 2 месяца
Сообщений: 27286
Продолжаем открывать для публичного доступа новый фукционал нашего сервиса анализа планов выполнения запросов в PostgreSQL explain.tensor.ru. Сегодня мы научимся определять больные места навскидку в больших и сложных планах, лишь мельком взглянув на них вооруженным глазом…
В этом нам помогут различные варианты визуализации:
Сокращенный текстовый вид
Оригинальный текст достаточно несложного плана уже вызывает проблемы при анализе:
Поэтому мы предпочитаем сокращенный вид, когда влево-вправо вынесена ключевая информация о времени выполнения и использованных buffers каждого узла, и очень просто заметить максимумы:
Круговая диаграмма
Но иногда даже просто понять «где болит сильнее всего» непросто, особенно, если он содержит несколько десятков узлов и даже сокращенная форма плана занимает 2-3 экрана.
В этом случае на помощь придет обычная круговая диаграмма:
Сразу, навскидку, видна примерная доля потребления ресурсов каждым из узлов. При наведении на него, слева в текстовом представлении мы увидим иконку у выбранного узла.
Плитка
Увы, piechart плохо показывает отношения между разными узлами и «самые горячие» точки. Для этого гораздо лучше подойдет вариант отображения «плиткой»:
Диаграмма выполнения
Но оба эти варианта не показывают полную цепочку вложений служебных узлов CTE/InitPlain/SubPlan — его можно увидеть только на диаграмме реального выполнения:
Нужно больше метрик!
Если вы снимаете план реального выполнения запроса как EXPLAIN (ANALYZE), то увидите там только затраченное время. Но очень часто этого недостаточно для правильных выводов!
Например, выполняя запрос на «непрогретом» кэше вы получите (но не увидите!) время получения данных с носителя, а вовсе не работы самого запроса.
Поэтому пара рекомендаций:
- Используйте EXPLAIN (ANALYZE, BUFFERS), чтобы увидеть объем вычитываемых страниц данных. Эта величина практически не подвержена колебаниям от нагрузки самого сервера и может быть использована в качестве метрики при оптимизации.
- Используйте track_io_timing, чтобы понимать, сколько именно времени заняла работа с носителем.
И вот если ваш план содержит не только время, но и buffers или i/o timings, то на каждой из вариантов диаграмм вы сможете переключиться в режим анализа этих метрик. Иногда можно сразу увидеть, например, что больше половины всех чтений пришлось на единственный проблемный узел:
Предыдущие статьи по теме:
- Понимаем планы PostgreSQL-запросов еще удобнее
- Рецепты для хворающих SQL-запросов
- О чем молчит EXPLAIN, и как его разговорить
===========
Источник:
habr.com
===========
Похожие новости:
- [Биотехнологии, Визуализация данных, Здоровье, Научно-популярное, Открытые данные] Коронавирус: первые итоги пандемии и карантина
- [PostgreSQL, SQL, Администрирование баз данных] Пишем и тестируем миграции БД с Alembic. Доклад Яндекса
- [PostgreSQL] Postgresso 23
- [Microsoft SQL Server, MySQL, PostgreSQL, Администрирование баз данных] DataGrip 2020.2: редактор больших значений, предпросмотр SQL при редактировании, новое отображение ячеек bool и другое
- [Big Data, Анализ и проектирование систем, Визуализация данных, Математика] Большие ошибки в больших данных: проблемы анализа на практике
- [PostgreSQL, Администрирование баз данных, Системное администрирование] Patroni Failure Stories or How to crash your PostgreSQL cluster. Алексей Лесовский
- [Системное администрирование, PostgreSQL, SQL, Администрирование баз данных] SQL HowTo: красивые отчеты по «дырявым» данным — GROUPING SETS
- [Google API, Python, Анализ и проектирование систем] Создание системы антифрода в такси с нуля
- [Open source, OpenStreetMap, Визуализация данных, Научно-популярное, Программирование] Делаем маршрутизацию (роутинг) на OpenStreetMap. Добавляем поддержку односторонних дорог
- [C, Визуализация данных, Звук, Инфографика, Разработка под Windows] Программное формирование мультисессии Adobe Audition с аудиозаписями телефонных звонков
Теги для поиска: #_postgresql, #_sql, #_administrirovanie_baz_dannyh (Администрирование баз данных), #_vizualizatsija_dannyh (Визуализация данных), #_postgresql, #_explain, #_explain.tensor.ru, #_blog_kompanii_tenzor (
Блог компании Тензор
), #_postgresql, #_sql, #_administrirovanie_baz_dannyh (
Администрирование баз данных
), #_vizualizatsija_dannyh (
Визуализация данных
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 28-Апр 04:29
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 2 месяца |
|
|
Продолжаем открывать для публичного доступа новый фукционал нашего сервиса анализа планов выполнения запросов в PostgreSQL explain.tensor.ru. Сегодня мы научимся определять больные места навскидку в больших и сложных планах, лишь мельком взглянув на них вооруженным глазом…  В этом нам помогут различные варианты визуализации:  Сокращенный текстовый вид Оригинальный текст достаточно несложного плана уже вызывает проблемы при анализе:  Поэтому мы предпочитаем сокращенный вид, когда влево-вправо вынесена ключевая информация о времени выполнения и использованных buffers каждого узла, и очень просто заметить максимумы:  Круговая диаграмма Но иногда даже просто понять «где болит сильнее всего» непросто, особенно, если он содержит несколько десятков узлов и даже сокращенная форма плана занимает 2-3 экрана.  В этом случае на помощь придет обычная круговая диаграмма:  Сразу, навскидку, видна примерная доля потребления ресурсов каждым из узлов. При наведении на него, слева в текстовом представлении мы увидим иконку у выбранного узла. Плитка Увы, piechart плохо показывает отношения между разными узлами и «самые горячие» точки. Для этого гораздо лучше подойдет вариант отображения «плиткой»:  Диаграмма выполнения Но оба эти варианта не показывают полную цепочку вложений служебных узлов CTE/InitPlain/SubPlan — его можно увидеть только на диаграмме реального выполнения:  Нужно больше метрик! Если вы снимаете план реального выполнения запроса как EXPLAIN (ANALYZE), то увидите там только затраченное время. Но очень часто этого недостаточно для правильных выводов! Например, выполняя запрос на «непрогретом» кэше вы получите (но не увидите!) время получения данных с носителя, а вовсе не работы самого запроса. Поэтому пара рекомендаций:
И вот если ваш план содержит не только время, но и buffers или i/o timings, то на каждой из вариантов диаграмм вы сможете переключиться в режим анализа этих метрик. Иногда можно сразу увидеть, например, что больше половины всех чтений пришлось на единственный проблемный узел:  Предыдущие статьи по теме:
=========== Источник: habr.com =========== Похожие новости:
Блог компании Тензор ), #_postgresql, #_sql, #_administrirovanie_baz_dannyh ( Администрирование баз данных ), #_vizualizatsija_dannyh ( Визуализация данных ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 28-Апр 04:29
Часовой пояс: UTC + 5