Комментарии 8
мы пользуемся pgpro_stats в связке с pgpro_pwr. Например, с его помощью можно сформировать отчёт за период, в котором произошёл инцидент, а потом детально сравнивать полученные данные с эталонной нагрузкой, когда всё работало.
Только при одном очень важном условии - "если есть данные с эталонной нагрузкой".
Маленький маячок - их нет.
Плюс , если формировать снимки pgpro_pwr согласно документации , периоды будут очень большие и бесполезны при инциденте.
Ну почему же нет? Если система вела себя нормально, а потом вдруг стала вести себя ненормально, то вот как раз и есть с чем сравнить.
Стандартная ситуация в продуктивном контуре :
1) Нагрузка 10 активных сессий . Все летает.
2) Нагрузка 100 активных сессий . Всё тормозит.
Какую полезную информацию для решения инцидента производительности СУБД можно получить сравнивая снимки pgpro_pwr ?
И самый главный вопрос - как решить инцидент в данной ситуации ?
И вопрос вопросов на последок - что значить нормально и ненормально ? В цифрах и метриках а не в ощущениях .
Нормально — это когда всех всё устраивало, ненормально — когда были жалобы на работу.
Если при нагрузке в 100 сессий всё стало тормозить, то как раз можно посмотреть, что именно поменялось. Если характер работы не поменялся, планы запросов остались теми же, сам набор запросов тоже более-менее сохранился, то значит система не тянет 100 сессий. Может даже получится увидеть какой именно ресурс стал узким местом. При увеличении сессий это чаще всего память — или общая память системы кончилась, или размер кеша СУБД недостаточен и данные в нём постоянно вытесняются. Или сессии друг другу мешают из-за конкуренции, например, взаимоблокировок.
В зависимости от того, что стало причиной, будут и рекомендации по устранению.
И главное — я понимал, что это поможет мне погрузиться в PostgreSQL, с которой я на тот момент никогда не работал
А прямо сейчас так можно? А то куда не пойди, везде коммерческий опыт спрашивают.
В целом техподдержка — хорошая стартовая площадка, чтобы «войти в IT».
А выйти из IT? Если, допустим, по culture-fit не берут в бекенд? Большой и разнообразный опыт должен же быть плюсом?
Ещё бывает, что клиент просит рассудить спор разработчика с администратором баз данных.
Можно вспомнить случай , когда разработчик пытался объяснить специалистам Postgres Pro , что легковесные блокировки в PostgreSQL работают неправильно и вообще с приложением проблем нет, нужно подобрать магическую комбинацию конфигурационных параметров.
Было довольно занятно слушать.
Главное — глубоко знать продукт: этого может быть достаточно
и статьи не нужны
Пятничные заявки и 6 ТБ WAL: будни инженера поддержки Postgres Professional