Оптимизация PostgreSQL: 10 параметров для роста производительности 2026

Дефолтный postgresql.conf оптимизирован под Raspberry Pi, а не под прод. На реальном сервере с 64 ГБ RAM правильный тюнинг даёт прирост 3-10х без единой строчки изменений в коде. Команда 1IT обкатала эти настройки на 200+ инсталляциях — делимся проверенными формулами.

Память: shared_buffers и effective_cache_size

• shared_buffers = 25% RAM (для 64 ГБ → 16 ГБ)
• effective_cache_size = 50-75% RAM (подсказка планировщику)
• work_mem = (RAM - shared_buffers) / (max_connections × 3)
• maintenance_work_mem = 1-2 ГБ (для VACUUM, CREATE INDEX)
• huge_pages = try (на Linux обязательно настроить vm.nr_hugepages)

WAL и checkpoint: убираем штормы записи

1. wal_buffers = 16 МБ (или -1 для авто)
2. checkpoint_timeout = 15min (вместо 5min по умолчанию)
3. max_wal_size = 8-16 ГБ для нагруженных систем
4. checkpoint_completion_target = 0.9 — растягиваем запись
5. wal_compression = on — экономит 30-50% WAL-трафика

Autovacuum: главный источник тормозов

Дефолтный autovacuum слишком ленив для OLTP. На горячих таблицах он не успевает чистить мёртвые строки, и таблица распухает в 3-5 раз. Решение — агрессивные настройки на уровне таблицы.

• autovacuum_max_workers = 4-8 (по числу ядер)
• autovacuum_naptime = 10s
• autovacuum_vacuum_scale_factor = 0.05 (5% мёртвых строк)
• autovacuum_vacuum_cost_limit = 2000 (по умолчанию 200 — слишком медленно)
• Для горячих таблиц: ALTER TABLE ... SET (autovacuum_vacuum_scale_factor = 0.01)

Планировщик и параллелизм

• random_page_cost = 1.1 для SSD (вместо 4.0)
• effective_io_concurrency = 200-300 для NVMe
• max_parallel_workers_per_gather = 4
• max_parallel_workers = 8-16
• jit = off для OLTP, on для аналитики

Мониторинг: что и как смотреть

Без pg_stat_statements тюнинг — это гадание. Включайте сразу после установки: shared_preload_libraries = 'pg_stat_statements'. Топ-20 запросов по total_exec_time покажут 80% узких мест.