Comments 11
По поводу Duration, есть пара вопросов:
1)
А разве поле total_time показывает не общее время выполнения запроса?
2) Получить историю времени выполнения конкретного запроса нельзя?
Далее.
А можно примеры подсказок?
1)
total_time. Это поле показывает в миллисекундах время выполнения (включая ожидание) для каждого типа запросов.
А разве поле total_time показывает не общее время выполнения запроса?
2) Получить историю времени выполнения конкретного запроса нельзя?
Далее.
если ваш Postgres злоупотребляет ошибками, idle транзакциями или блокировками, то Weaponry подскажет что делать.
А можно примеры подсказок?
0
1) total_time показывает сумму всех времен выполнения этого запроса, условно говоря если запрос выполняется ~1ms и выполнялся 1000 раз, то в total time будет ~1000 (ms).
2) Через pg_stat_statements увы нет, нельзя. там только агрегаты. Точное время выполнения конкретного запроса можно получить через логи (при условии что логирование настроено).
3) Пока подсказки довольно простые и просто указывают на наличие проблемы и пути дальнейшего действий что с этим делать. Например для idle транзакций устранить их в приложении, включить автоматическое завершение idle транзакций по таймауту и т.д.
2) Через pg_stat_statements увы нет, нельзя. там только агрегаты. Точное время выполнения конкретного запроса можно получить через логи (при условии что логирование настроено).
3) Пока подсказки довольно простые и просто указывают на наличие проблемы и пути дальнейшего действий что с этим делать. Например для idle транзакций устранить их в приложении, включить автоматическое завершение idle транзакций по таймауту и т.д.
0
3) Пока подсказки довольно простые
ну вот например по блокировкам и ожиданиям, какие будут подсказки?
Можно увидеть, что один запрос находится в ожидании и заблокирован другим запросом?
ну например есть у меня запрос. Всегда выполнялся пусть 1 секунду, а сейчас 5 секунд. Почему?
Дашбоард показанный в статье поможет?
0
> ну вот например по блокировкам и ожиданиям, какие будут подсказки?
сначала посмотрим включен ли log_lock_waits, если не включен то скажем включить и через некоторое время проверить логи. Если уже включен, скажем смотреть логи на предмет waiting и дальше инспектировать приложение и фиксить там.
> Можно увидеть, что один запрос находится в ожидании и заблокирован другим запросом?
Не, пока такого нет
> ну например есть у меня запрос. Всегда выполнялся пусть 1 секунду, а сейчас 5 секунд. Почему?
Дашбоард показанный в статье поможет?
Если запрос всего один, то есть вероятность что он потеряется на фоне других (при большом rate). Если таких запросов много, то вы пятикратное увеличение времени вы увидите в durations. Ну а дальше надо идти в отдельный дашборд в котором собрана стата по запросам и там смотреть что за тип запросов стал выполняться дольше (а затем explain и вот это все).
Задача RED и Golden Signals дать способ быстро ответить на вопрос, все хорошо с сервисом. Детали работы сервиса уже покрываются отдельными метриками.
сначала посмотрим включен ли log_lock_waits, если не включен то скажем включить и через некоторое время проверить логи. Если уже включен, скажем смотреть логи на предмет waiting и дальше инспектировать приложение и фиксить там.
> Можно увидеть, что один запрос находится в ожидании и заблокирован другим запросом?
Не, пока такого нет
> ну например есть у меня запрос. Всегда выполнялся пусть 1 секунду, а сейчас 5 секунд. Почему?
Дашбоард показанный в статье поможет?
Если запрос всего один, то есть вероятность что он потеряется на фоне других (при большом rate). Если таких запросов много, то вы пятикратное увеличение времени вы увидите в durations. Ну а дальше надо идти в отдельный дашборд в котором собрана стата по запросам и там смотреть что за тип запросов стал выполняться дольше (а затем explain и вот это все).
Задача RED и Golden Signals дать способ быстро ответить на вопрос, все хорошо с сервисом. Детали работы сервиса уже покрываются отдельными метриками.
0
Спасибо, очень интересно — аж сразу захотелось реализовать подобное (на работе как раз postgres) :)
Есть только один вопрос — что есмь RED и Golden Signals, где это брать и с чем это едят? Если есть инфа длякранов нубов — то поделитесь, пожалуйста :)
Зы. гуглить-то, я, теоретически, умею, но хотелось бы услышать совета от профессионалов дабы сэкономить вагончик времени :) заранее спасибо!
Есть только один вопрос — что есмь RED и Golden Signals, где это брать и с чем это едят? Если есть инфа для
Зы. гуглить-то, я, теоретически, умею, но хотелось бы услышать совета от профессионалов дабы сэкономить вагончик времени :) заранее спасибо!
0
RED и Golden Signals это набор метрик для поверхностной оценки состояния сервиса. Первым появился GS в недрах гугла, почитать можно в SRE Book, RED это уже наложение USE метода на GS. Суть методов в том что сервис обрабатывает запросы, часть из них может быть ошибочными, и запросы обрабатываются с разными временем. Получается что накладывая метрики на то как обрабатываются запросы, мы можем оценить насколько хорошо справляется наш сервис со своей работой или нет. Если вы не знакомы с темой рекомендую начать с приведенных ссылок.
0
Алексей, спасибо за полезные запросы к pg_stat_activity.
Добавлю, что при наличии микросервисов удобно группировать метрики из pg_stat_activity по usename. Чтобы сопоставлять "idle in transaction" с конкретным сервисом.
0
И дополнительно можно группировать pg_stat_activity по ключу
md5(query)::uuid::varchar(100) as query_md5
А если места не жалко, то можно просто по
left(regexp_replace(query, '\\r|\\n|\\t|\\s+', ' ', 'g'), 1000) query
Тогда для "idle in transaction" накапливается статистика о запросах, после которых транзакция зависла. md5 можно сопоставить с md5 из pg_stat_statements. А query сам по себе интересен. В МакроСервисах кода много и текст query может быстрее привести к месту в коде, где транзакции обрываются.
0
Алексей, спасибо статью и свое виденье
Для глубокого анализа происходящего можно поставить расширение pg_profile по средствам которого можно поднять историю происходящего и детально разбираться Андрей рассказывает как это работает
Для глубокого анализа происходящего можно поставить расширение pg_profile по средствам которого можно поднять историю происходящего и детально разбираться Андрей рассказывает как это работает
0
Sign up to leave a comment.
PostgreSQL, RED, Golden Signals: руководство к действию