Параметры БД не настраивают «на глаз»: сначала нагрузка, потом тюнинг

Параметры БД не настраивают «на глаз»: сначала нагрузка, потом тюнинг

Коллеги, давайте разберем план выполнения. Конфигурация БД — это не список «рекомендуемых значений», а набор рычагов под конкретный профиль нагрузки.

Сначала снимаем базу: CPU, I/O, память, latency запросов, конкуренцию за блокировки, объемы сортировок и spill в temp. Без этого легко ускорить один тяжелый отчет и одновременно положить OLTP.

Дальше правим только то, что видно в симптомах:
• мало памяти на кэш — растут чтения с диска;
• маленькие буферы WAL/redo — упираемся в запись;
• агрессивный autovacuum/maintenance — ловим фоновые пики;
• неверный work_mem/sort memory — уходим в диск на сортировках и хешах.

Схема простая, но дьявол кроется в статистике. Один и тот же параметр может быть полезен для batch-задач и вреден для коротких транзакций, если открыть его слишком широко на весь сервер.

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