title

text

Владимир Хаймин
Владимир Хаймин Банк ВТБ (ПАО) Администратор PostgreSQL
40 мин

Определение фактического профиля нагрузки в PostgreSQL. Динамические состояния.

Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить фактический профиль системы именно сейчас?

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

Так же я хотел бы показать в чем особенности других профилей нагрузки. Например, если База Данных переведена в Архив, но выясняется, что в действительности ведет себя как скрытый ПРОД и активно используется. Как это выявить по метрикам?

Другие доклады