![Слепцы ощупывают различные аспекты слона Слепцы ощупывают различные аспекты слона](https://habrastorage.org/getpro/habr/upload_files/349/b97/e71/349b97e71de03d36f853bea4198586ef.jpeg)
Наверняка, многие из вас пользуются explain.tensor.ru - нашим сервисом визуализации PostgreSQL-планов или уже даже развернули его на своей площадке. Но визуализация конкретного плана - это лишь небольшая помощь разработчику, поэтому в "Тензоре" мы создали сервис, который позволяет увидеть сразу многие аспекты работы сервера:
медленные или гигантские запросы
возникающие блокировки и ошибки
частоту и результаты проходов
[auto]VACUUM/ANALYZE
И сегодня мы, наконец, готовы представить вам демо-режим этого сервиса, куда вы самостоятельно можете загрузить лог своего PostgreSQL-сервера и наглядно увидеть, чем он у вас занимается.
Что и как можно анализировать, вы можете узнать в серии моих лекций.
В качестве примера мы подключили сюда несколько своих серверов, данные с которых собираются в онлайн-режиме.
Проблемные запросы
![Проблемные запросы по шаблонам Проблемные запросы по шаблонам](https://habrastorage.org/getpro/habr/upload_files/ef1/fd2/451/ef1fd24511b15574a31ca46a1030abb2.png)
Чтобы включить сброс анализа выполняемых запросов прямо из активной сессии можно воспользоваться такой конструкцией:
SET log_min_duration_statement = '1ms'; -- пишем в лог все запросы дольше 1ms
LOAD 'auto_explain'; -- загружаем модуль auto_explain
SET auto_explain.log_min_duration = '1ms'; -- снимаем план, если дольше 1ms
SET auto_explain.log_analyze = 'on'; -- план пишем как EXPLAIN (ANALYZE, BUFFERS)
SET auto_explain.log_buffers = 'on';
SET auto_explain.log_timing = 'on';
SET auto_explain.log_triggers = 'on'; -- и триггеры тоже
SET track_io_timing = 'on'; -- выводить в план время IO-операций
Но лучше все-таки установить нужные параметры auto_explain прямо в конфиге сервера.
По шаблонам
Очищаем все планы от переменных составляющих, агрегируем - и видим не только "кто самое слабое звено", но и подробное распределение запросов с такими планами во времени:
![Тепловая карта распределения длительности запросов по шаблону Тепловая карта распределения длительности запросов по шаблону](https://habrastorage.org/getpro/habr/upload_files/b05/117/191/b05117191f843656999fa8c057c629f3.png)
По моделям
Очищаем планы еще сильнее, сводя все к моделям доступа в определенные таблицы - и получаем кластерный анализ планов:
![Кластер планов запросов Кластер планов запросов](https://habrastorage.org/r/w1560/getpro/habr/upload_files/be0/5c6/26e/be05c626ec9a13dce672f5f1900bd448.png)
По приложениям
Берем из application_name
название того, кто делал запрос - и узнаем, кому мы обязаны наибольшей нагрузкой в течение дня:
![Проблемные запросы по приложениям Проблемные запросы по приложениям](https://habrastorage.org/getpro/habr/upload_files/5d7/8bf/7b7/5d78bf7b7bf62add84b38f6824679949.png)
По объектам
Хотите узнать, при чтении из какой таблицы отбрасывалось максимум записей? На каких узлах плана потрачено больше всего времени? Тогда вам сюда:
![Статистика по объектам БД Статистика по объектам БД](https://habrastorage.org/getpro/habr/upload_files/2a5/4e5/f4d/2a54e5f4d0308217e75784d19f471ec0.png)
По триггерам
Возможно, у вас большая часть логики (а заодно и производительности) в базе скрывается внутри триггеров - welcome:
![Статистика вызовов триггеров Статистика вызовов триггеров](https://habrastorage.org/getpro/habr/upload_files/de7/3c1/2b2/de73c12b2fb92d226bfc746ac1a684dc.png)
По времени и ресурсам
Здесь вы можете увидеть топ самых "прожорливых" запросов за сутки.
Мегазапросы
В статье PostgreSQL Antipatterns: «слишком много золота» я уже рассказывал, почему запросы с огромными списками параметров в теле - это плохо. И большие resultset'ы - тоже не очень хорошо.
Вот тут мы их и ловим - все, которые гонят больше 1MB трафика в ту или другую сторону.
Блокировки
Кто, где, когда, на чем споткнулся и попал на ожидание блокировки или на deadlock? Вот они все здесь:
![Сводка по блокировкам Сводка по блокировкам](https://habrastorage.org/getpro/habr/upload_files/07f/b64/343/07fb643439cfd0756c1ba549c63c6bbd.png)
А вот здесь - статья "DBA: кто скрывается за блокировкой", которая поможет понять, что тут вообще происходило.
Блокировки - это нормально. Ненормально, когда они слишком велики - то есть превышают deadlock_timeout при включенном log_lock_waits.
Ошибки
Из лога мы получаем все ошибки (FATAL/ERROR/WARNING
), а дальше - расклассифицируем по кучкам:
![Классы ошибок Классы ошибок](https://habrastorage.org/getpro/habr/upload_files/7bc/2f8/83e/7bc2f883e9d1852b0118efd19cb22f2a.png)
Что выводить в лог, указывают параметры log_min_messages и log_min_error_statement.
Системные действия
Не слишком ли часто бегает autovacuum? Может, он цепляет секции, которые не должен бы? Прочитайте "DBA: Ночной Дозор", чтобы увидеть пример, как использовать мониторинг системных действий для снижения нагрузки на базу.
![Статистика autovacuum Статистика autovacuum](https://habrastorage.org/getpro/habr/upload_files/c39/8f2/512/c398f2512604292b5170ec99d4fccf5d.png)
Настроить необходимую "чувствительность" лога поможет параметр log_autovacuum_min_duration.
Offline-режим
На сладкое.
Чтобы все это увидеть по собственному серверу - добавьте его в качестве offline-источника и загрузите лог PostgreSQL (демо-ограничение 100MB):
![Добавление offline-сервера Добавление offline-сервера](https://habrastorage.org/getpro/habr/upload_files/24b/f0b/497/24bf0b4974c7cfd8f4fd963919327a73.png)
Для корректного разбора лога вам понадобится указать значения log_line_prefix
и lc_messages
и кодировки развернутых баз:
SHOW log_line_prefix;
SHOW lc_messages;
SELECT datname, pg_encoding_to_char(encoding) FROM pg_database;
Однако, в демо-режиме осуществляется только разбор лога с lc_messages = 'en_US'
. То есть если в вашем лог-файле вместо 'LOG:'
выводится 'СООБЩЕНИЕ:'
- ничего не выйдет, увы.
Если же у вас не "ванильный" PostgreSQL, а какой-то форк - тут как повезет, в зависимости от совпадения общего формата лога.
Если вы хотите развернуть такой же сервис у себя или предложить, как его усовершенствовать - пишите в комментах, в личку или на kilor@tensor.ru.