PostgreSQL
Database Administration
Comments 7
0

Парсить журнал — это, конечно, смело, но примерно безнадежно. pgBadger этом вон уж сколько занимается, и то не все гладко… А смысл? Почему pg_stat_statements не ограничиться?

0

Но как из pg_stat_statements получить актуальный текст запроса с параметрами? А текст запроса нужен 1-чтобы выполнить explain, 2-чтобы получить хеш текста запроса и определить поменялся план выполнения по причине изменения запроса или по другой причине.
Идея была такая. По опыту решения инцидентов по производительности запросов, идея вполне себя оправдала.

0

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

0

Да, согласен, в данном виде это реальный костыль. Но другого средства получить историю планов выполнения придумать пока не удалось.
По поводу подозрений о неполных данных, да, уверен, при серьезной нагрузке будут проблемы.
Но по опыту использования в реальном продакшн, для нечасто выполняемых запросах — работает.
Для нагруженных систем придется ждать когда ядро будет выдавать идентификатор запроса и план, как в Оракле. Но учитывая то, что запросы в Оракле и PostgreSQL выполняются по разному, у меня есть некоторые сомнения. Но может быть, я ошибаюсь.
По поводу актуальности планов, повторюсь, для не OLTP проблем не было.

0
По поводу получения актуального текста запроса для хранения планов выполнения.
В ходе исследований выяснилось, что парсить лог для этого вообще говоря не обязательно.
Актуальный текст запроса уже имеется в pg_stat_activity. И если есть история pg_stat_activity, а она есть. То получить историю плана выполнения становится несколько проще. Хотя предположу, парсить лог все равно придется, иначе довольно проблематично получить точное время выполнения запроса. В истории pg_stat_activity возможны дыры. Но вот если история будет собираться в ядре, то дыр не будет, конечно. Но в этом случае резко возрастет импакт на ядро и на дискт конечно. Поэтому не думаю, что в обозримом будущем данная фича будет реализована в ядре. Как сторонний инструмент, да, есть уже сейчас.
Сейчас, как раз работаю над этой возможностью.
0

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

0
Да, на проблемы с размером запроса приходилось натыкаться.
Хотя конечно ситуация очень редкая. Придется что-то выдумывать, наверное.
Парсить лог имеет смысл для получения точной длительности выполнения. Приблизительно можно получить из истории pg_stat_activity.

Пока не пришел к окончательному мнению что важнее — иметь точную длительность выполнения или избавиться от процедуры чтения и парсинга текстового файла.
Для мониторинга конечно точное время выполнения важно, но в случае большой нагрузки парсинг занимает недопустимое время(что неудивительно). В общем, есть еще над чем подумать. Пока все таки склоняюсь к отказу от парсинга лога. Тем более на баше это та еще процедура ;-(
Only those users with full accounts are able to leave comments., please.