Pull to refresh

Comments 7

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

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

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

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

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

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

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

Пока не пришел к окончательному мнению что важнее — иметь точную длительность выполнения или избавиться от процедуры чтения и парсинга текстового файла.
Для мониторинга конечно точное время выполнения важно, но в случае большой нагрузки парсинг занимает недопустимое время(что неудивительно). В общем, есть еще над чем подумать. Пока все таки склоняюсь к отказу от парсинга лога. Тем более на баше это та еще процедура ;-(
Sign up to leave a comment.

Articles