Всем привет!

Мне сильно нужен был механизм, подобный оракловому AWR. Хороших и простых готовых аналогов не нашел, и решил сделать свой. Модуль выполнен в виде extension, так что относительно легко устанавливается и обновляется при выходе новых версий. Написан на чистом pl/pgsql, так что прост в понимании.
Представляю модуль широкой общественности - пригодится и DBA и разработчикам. Особе ценна будет обратная связь - может кто багу найдет, или какие-нибудь пожелания дополнительные возникнут...

Положил сюда:
https://github.com/zubkov-andrei/pg_profile

mefman,

Поправьте меня если я ошибаюсь, но мне кажется что эта утилита работает исключительно с текстовыми логами сервера... Посмотрел поверхностно только сейчас, не знаю, попадают ли в текстовый лог данные, достаточные для получения данных, подобных pg_stat_statements. Не говоря уже о том, что логирование всех запросов, происходящих на сервере в текстовый лог сильно влияет на производительность...
Ну и в моем модуле есть данные не только по запросам, а еще и по различным объектам схем. Короче, по данным статистических представлений, доступных в PostgreSQL.

ora601,

К сожалению, самописных вьюх никак недостаточно - обязательно нужно где-то хранить данные в предыдущие моменты времени. Ни одна вьюха в прошлое заглянуть не может. Нужны таблицы, и в них надо периодически данные складывать.

Предлагаемый механизм как раз избавляет администратора от необходимости городить весь этот огород - поставил один extension и можешь с его помощью отчеты строить, все самое нужное, на мой взгляд, в нем есть.

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

По поводу wait events версии 9.6. В дело можно пустить только статистики ожидания - накопленные суммы времени ожиданий для разных серверных процессов. Такого в PostgreSQL еще нет. Все что есть - это возможность по запросу в pg_stat_activity понять чего процесс ждет именно сейчас, но без времени ожидания данные эти бесполезны. Не говоря о том, что для того чтобы получить общую картину запросы эти необходимо выполнять часто, и это все равно не даст сколь-нибудь достоверных данных. Так что wait events, до сих пор невозможен.

ora601Иронично что разработчики самого постгрес тормозят развитие хороших мониторинг тулс.
На всё есть довольно веские причины, скорее всего архитектурного характера. Если бы это было просто - давно бы сделали.

ora601Depends, запросы то бывают разные по продолжительности, если его положить на любой другой диск то не такой уж и оверхед, ну разве что CPU остаеться да.
Понятно, что для какого-нибудь неподъемного DSS/DW можно и логи анализировать. Но это же не универсальное решение, так же как добавление в конфигурацию отдельных дисков, SSD, рамдисков и прочего такого же... Подозреваю что на нагруженной системе лог будет за час расти настолько что его тупо негде будет хранить (особенно, учитывая что хранилище должно быть относительно быстрым), не говоря уже о времени, необходимом на парсинг.

PgSQLanonymous3Почему? Зачастую это самое эффективное решение.
А каковы критерии эффективности? Иначе это вода в ступе...
Я разрабатывал свой модуль преследуя следующие основные критерии эффективности:
- Простота установки и использования. Минимум необходимых действий и отсутствие необходимости в установке и настройке дополнительного ПО
- Отсутствие необходимости в изменении аппаратного ландшафта.
- Минимальное воздействие на производительность СУБД.

PgSQLanonymous3Я слышал, что многие используют как раз на высоконагруженных системах...
Кстати: http://blog.endpoint.com/2012/06/logstatement-postgres-all-full-logging.html

Сходил, почитал... И что мы там видим? Надо воткнуть в сервер отдельные диски для логов, настроить специальным образом файловые системы, оптимизируя запись логов, при большом росте логов отправлять их в сторонку на отдельный сервер или (о ужас) на ленту. Разве это может считаться удобным универсальным решением?

acidophilusбагов полагаю там полно
А я тоже так думаю. Вот поэтому я и опубликовал модуль. Возможно Вы найдете парочку багов, сообщите мне, и модуль станет лучше, а всем кто будет его использовать станет немного легче жить.

Положил сегодня свежее обновление, поправил довольно много разных ошибок и применил генерацию (и агрегирование статистик) queryid по аналогии с pgcenter.

По прежнему жду конструктивных отзывов :)

Да, на регулярные обновления времени как обычно не хватает, но как раз вчера опубликовал свежую версию. Теперь можно строить сравнительные отчеты.