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

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

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

Рабочий порядок такой:
— зафиксировать базовую нагрузку: latency, TPS, cache hit, waits, блокировки;
— понять, что ограничивает систему: CPU, RAM, диск или сеть;
— менять по одному параметру и смотреть дельту, а не «в целом стало бодрее»;
— после каждого шага проверять план, статистику и фоновые процессы.

Самые опасные настройки — память, размер буферов, число worker’ов и агрессивность автосборки мусора/обслуживания. Если поднять их без расчёта, получите не ускорение, а рост свопа, очередей и пауз. Схема простая, но дьявол кроется в статистике: планировщик верит в цифры, а не в надежды администратора.

Ещё один важный момент: конфиг не лечит плохие запросы. Если full scan жрёт диск, а соединение тащит лишние поля, увеличение буферов только отложит проблему. Сначала мониторинг, потом индексы; потом — аккуратная настройка параметров.

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