Наверняка, многие из вас пользуются explain.tensor.ru - нашим сервисом визуализации PostgreSQL-планов или уже даже развернули его на своей площадке. Но визуализация конкретного плана - это лишь небольшая помощь разработчику, поэтому в "Тензоре" мы создали сервис, который позволяет увидеть сразу многие аспекты работы сервера: медленные или гигантские запросы возникающие блокировки и ошибки частоту и результаты проходов [auto]VACUUM/ANALYZE И сегодня мы, наконец, готовы представить вам демо-режим этого сервиса, куда вы самостоятельно можете загрузить лог своего PostgreSQL-сервера и наглядно увидеть, чем он у вас занимается. Что и как можно анализировать, вы можете узнать в серии моих лекций. В качестве примера мы подключили сюда несколько своих серверов, данные с которых собираются в онлайн-режиме. Чтобы включить сброс анализа выполняемых запросов прямо из активной сессии можно воспользоваться такой конструкцией: Но лучше все-таки установить нужные параметры auto_explain прямо в конфиге сервера. Очищаем все планы от переменных составляющих, агрегируем - и видим не только "кто самое слабое звено", но и подробное распределение запросов с такими планами во времени: Очищаем планы еще сильнее, сводя все к моделям доступа в определенные таблицы - и получаем кластерный анализ планов: Берем из application_name название того, кто делал запрос - и узнаем, кому мы обязаны наибольшей нагрузкой в течение дня: Хотите узнать, при чтении из какой таблицы отбрасывалось максимум записей? На каких узлах плана потрачено больше всего времени? Тогда вам сюда: Возможно, у вас большая часть логики (а заодно и производительности) в базе скрывается внутри триггеров - welcome: Здесь вы можете увидеть топ самых "прожорливых" запросов за сутки. В статье PostgreSQL Antipatterns: «слишком много золота» я уже рассказывал, почему запросы с огромными списками параметров в теле - это плохо. И большие resultset'ы - тоже не очень хорошо. Вот тут мы их и ловим - все, которые гонят больше 1MB трафика в ту или другую сторону. Кто, где, когда, на чем споткнулся и попал на ожидание блокировки или на deadlock? Вот они все здесь: А вот здесь - статья "DBA: кто скрывается за блокировкой", которая поможет понять, что тут вообще происходило. Блокировки - это нормально. Ненормально, когда они слишком велики - то есть превышают deadlock_timeout при включенном log_lock_waits. Из лога мы получаем все ошибки (FATAL/ERROR/WARNING), а дальше - расклассифицируем по кучкам: Что выводить в лог, указывают параметры log_min_messages  и log_min_error_statement. Не слишком ли часто бегает autovacuum? Может, он цепляет секции, которые не должен бы? Прочитайте "DBA: Ночной Дозор", чтобы увидеть пример, как использовать мониторинг системных действий для снижения нагрузки на базу. Настроить необходимую "чувствительность" лога поможет параметр log_autovacuum_min_duration. На сладкое. Чтобы все это увидеть по собственному серверу - добавьте его в качестве offline-источника и загрузите лог PostgreSQL (демо-ограничение 100MB): Для корректного разбора лога вам понадобится указать значения log_line_prefix и lc_messages и кодировки развернутых баз: Однако, в демо-режиме осуществляется только разбор лога с lc_messages = 'en_US'. То есть если в вашем лог-файле вместо 'LOG:' выводится 'СООБЩЕНИЕ:' - ничего не выйдет, увы. Если же у вас не "ванильный" PostgreSQL, а какой-то форк - тут как повезет, в зависимости от совпадения общего формата лога. Если вы хотите развернуть такой же сервис у себя или предложить, как его усовершенствовать - пишите в комментах, в личку или на kilor@tensor.ru.  Архитектура ИС: PostgreSQL, Node.js и highload