Продолжаем открывать для публичного доступа новый функционал нашего сервиса анализа планов выполнения запросов в PostgreSQL explain.tensor.ru. Сегодня мы научимся определять больные места навскидку в больших и сложных планах, лишь мельком взглянув на них вооруженным глазом…
![](https://habrastorage.org/webt/z3/ps/cw/z3pscwbe6oykanpwxnhqipqx9tu.png)
В этом нам помогут различные варианты визуализации:
![](https://habrastorage.org/webt/s6/a5/bk/s6a5bkmyxfsgq4-sou3koei5gme.gif)
Оригинальный текст достаточно несложного плана уже вызывает проблемы при анализе:
![](https://habrastorage.org/webt/dh/te/vq/dhtevqrbfm987ozs_4ywx7oqar0.png)
Поэтому мы предпочитаем сокращенный вид, когда влево-вправо вынесена ключевая информация о времени выполнения и использованных buffers каждого узла, и очень просто заметить максимумы:
![](https://habrastorage.org/webt/qe/o-/li/qeo-linervxcdn_mh1cjifo4uju.png)
Но иногда даже просто понять «где болит сильнее всего» непросто, особенно, если он содержит несколько десятков узлов и даже сокращенная форма плана занимает 2-3 экрана.
![](https://habrastorage.org/webt/3p/wu/ze/3pwuzeal4rrjhmhfnameub7wvkg.png)
В этом случае на помощь придет обычная круговая диаграмма:
![](https://habrastorage.org/webt/v0/i8/hj/v0i8hjg1dosen7u_dxccltfug94.png)
Сразу, навскидку, видна примерная доля потребления ресурсов каждым из узлов. При наведении на него, слева в текстовом представлении мы увидим иконку у выбранного узла.
Увы, piechart плохо показывает отношения между разными узлами и «самые горячие» точки. Для этого гораздо лучше подойдет вариант отображения «плиткой»:
![](https://habrastorage.org/webt/av/aj/ia/avajiajenjjatdarbbqgapm3gn4.png)
Но оба эти варианта не показывают полную цепочку вложений служебных узлов
![](https://habrastorage.org/webt/j5/9o/cj/j59ocjjy-5p0pc3d6dtm-weexim.png)
Если вы снимаете план реального выполнения запроса как
Например, выполняя запрос на «непрогретом» кэше вы получите (но не увидите!) время получения данных с носителя, а вовсе не работы самого запроса.
Поэтому пара рекомендаций:
И вот если ваш план содержит не только время, но и
![](https://habrastorage.org/webt/-s/dp/q5/-sdpq5ov42pirqbxwngi8xaiuoo.png)
Предыдущие статьи по теме:
![](https://habrastorage.org/webt/z3/ps/cw/z3pscwbe6oykanpwxnhqipqx9tu.png)
В этом нам помогут различные варианты визуализации:
![](https://habrastorage.org/webt/s6/a5/bk/s6a5bkmyxfsgq4-sou3koei5gme.gif)
Сокращенный текстовый вид
Оригинальный текст достаточно несложного плана уже вызывает проблемы при анализе:
![](https://habrastorage.org/webt/dh/te/vq/dhtevqrbfm987ozs_4ywx7oqar0.png)
Поэтому мы предпочитаем сокращенный вид, когда влево-вправо вынесена ключевая информация о времени выполнения и использованных buffers каждого узла, и очень просто заметить максимумы:
![](https://habrastorage.org/webt/qe/o-/li/qeo-linervxcdn_mh1cjifo4uju.png)
Круговая диаграмма
Но иногда даже просто понять «где болит сильнее всего» непросто, особенно, если он содержит несколько десятков узлов и даже сокращенная форма плана занимает 2-3 экрана.
![](https://habrastorage.org/webt/3p/wu/ze/3pwuzeal4rrjhmhfnameub7wvkg.png)
В этом случае на помощь придет обычная круговая диаграмма:
![](https://habrastorage.org/webt/v0/i8/hj/v0i8hjg1dosen7u_dxccltfug94.png)
Сразу, навскидку, видна примерная доля потребления ресурсов каждым из узлов. При наведении на него, слева в текстовом представлении мы увидим иконку у выбранного узла.
Плитка
Увы, piechart плохо показывает отношения между разными узлами и «самые горячие» точки. Для этого гораздо лучше подойдет вариант отображения «плиткой»:
![](https://habrastorage.org/webt/av/aj/ia/avajiajenjjatdarbbqgapm3gn4.png)
Диаграмма выполнения
Но оба эти варианта не показывают полную цепочку вложений служебных узлов
CTE/InitPlain/SubPlan
— его можно увидеть только на диаграмме реального выполнения:![](https://habrastorage.org/webt/j5/9o/cj/j59ocjjy-5p0pc3d6dtm-weexim.png)
Нужно больше метрик!
Если вы снимаете план реального выполнения запроса как
EXPLAIN (ANALYZE)
, то увидите там только затраченное время. Но очень часто этого недостаточно для правильных выводов!Например, выполняя запрос на «непрогретом» кэше вы получите (но не увидите!) время получения данных с носителя, а вовсе не работы самого запроса.
Поэтому пара рекомендаций:
- Используйте
EXPLAIN (ANALYZE, BUFFERS)
, чтобы увидеть объем вычитываемых страниц данных. Эта величина практически не подвержена колебаниям от нагрузки самого сервера и может быть использована в качестве метрики при оптимизации. - Используйте
track_io_timing
, чтобы понимать, сколько именно времени заняла работа с носителем.
И вот если ваш план содержит не только время, но и
buffers
или i/o timings
, то на каждой из вариантов диаграмм вы сможете переключиться в режим анализа этих метрик. Иногда можно сразу увидеть, например, что больше половины всех чтений пришлось на единственный проблемный узел:![](https://habrastorage.org/webt/-s/dp/q5/-sdpq5ov42pirqbxwngi8xaiuoo.png)
Предыдущие статьи по теме:
Fragster
Это прекрасно!