title

text

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

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

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

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