Параметры БД — не тюнинг на глаз: как не устроить себе тормоза

Параметры БД — не тюнинг на глаз: как не устроить себе тормоза

Коллеги, давайте разберем план выполнения. Конфиг БД нельзя «подкрутить» ради красоты: почти каждый параметр влияет на память, I/O или конкуренцию за ресурсы. Если менять всё подряд, получите не ускорение, а новый набор проблем.

Рабочий порядок такой:
— сначала снимите базовую картину: load, latency, cache hit, wait events, блокировки;
— меняйте один параметр за раз, иначе не поймёте, что именно сработало;
— фиксируйте до/после на одинаковой нагрузке, а не на «вроде стало легче»;
— проверяйте, не выросла ли цена оптимизации: больше RAM — меньше места под ОС, агрессивный кеш — больше риск вытеснения.

Схема простая, но дьявол кроется в статистике. Без актуальной статистики оптимизатор выбирает плохие планы, а без контроля I/O любой «улучшенный» кеш может просто перенести узкое место на диск. И да, параметр, который помогает на чтении, часто бьёт по записи или по параллельности.

Золотое правило: сначала мониторинг, потом индексы. То же самое и с конфигом: сначала понять профиль нагрузки, потом трогать память, чекпойнты, логирование, очереди и лимиты. В продакшене так лучше не делать, и вот почему: откат параметра занимает минуты, а деградация под пиком — уже инцидент.

Поменяли настройку — сразу проверьте план, wait’ы и реальный I/O. Если метрики не улучшились, не «дожимайте» параметр дальше: откат часто быстрее и дешевле.