В последние недели большую часть времени мне приходится заниматься мониторингом PostgreSQL.
Типичные болевые точки:
- Запросы выполняются долго
- Код написан не нами, и переписывем "по возможности"
Куда смотреть понимания нет, поэтому хотел бы рассказать о своем опыте, и том минимуме который стоит замониторить.
В первую очередь необходимо мониторить кол-во соединений к БД, как активных, так и idle.
Общее кол-во соединений в целом можно и через кол-во процессов мониторить, а активные через представление pg_stat_database.
Через это же представление мониторим кол-во записей по типам(тут могу немного ошибаться в терминологии, или не правильно выразиться, но речь идет о tuples), кол-во commit rollback операций.
Эти метрики позволят нам оценить как минимум нагрузку и кол-во операций в БД, так же понадобятся в сравнительном анализе(при выполнении определенных изменений в конфигурации, в рамках нескольких итераций отследить например кол-во операций и сопоставить с остальными матриками)
Следующим показателем у нас будут блокировки по типам, эти данные берем из pg_locks, по этим метрикам больше вопросов будет к разработчикам, в плане оптимизации запросов с целью избегания блокировок.
И последним будет представление pg_stat_statements, из которого мы берем информацию о кол-ве промахов мимо кэша или work_mem например - это прям явные сигналы к тому что необходимо оптимизировать те или иные параметры в postgresql.conf
И чуть не забыл - это представление pg_stat_all_tables из которого можно получить информацию о кол-ве последовательных сканирований и сканирований таблице по индексу, тоже очень важный параметр на который стоит заострять внимание разработчиков(или DBA если они у Вас есть. Хотя если они у Вас есть - представленная мною информация не очень пригодится, т.к. они и так лучше меня знают что надо делать и куда смотреть)
---
Подписывайтесь на наш телеграм канал, в котором можно узнать все самое интересное первым - t.me/...ins
1 минута
30 августа 2024