Комплексная настройка postgresql.conf для высоконагруженных баз данных 1С
- Низкая производительность сложных отчетов и запросов динамических списков 1С:Предприятие.
- Массовый сброс временных данных на диск (
temporary file: size ... bytes) вместо обработки в RAM. - Высокое потребление CPU планировщиком при неоптимальных значениях
random_page_cost. - Блокировки и деградация при параллельном проведении документов.
1. Базовый расчет ключевых параметров для сервера с 64GB RAM и NVMe
Отредактируйте /etc/postgresql/16/main/postgresql.conf (или postgresql.auto.conf):
# --- Память и буферы ---
shared_buffers = 16GB # 25% от общей RAM
effective_cache_size = 48GB # 75% от общей RAM
maintenance_work_mem = 2GB # Для ускорения CREATE INDEX и VACUUM
work_mem = 64MB # Память на одну операцию сортировки/хэша
# --- Планировщик под NVMe/SSD ---
random_page_cost = 1.1 # Для NVMe дисков (быстрый случайный доступ)
seq_page_cost = 1.0
effective_io_concurrency = 200 # Глубина очереди ввода-вывода для SSD
# --- Параллелизм (Параллельные запросы) ---
max_worker_processes = 16
max_parallel_workers = 16
max_parallel_workers_per_gather = 4
max_parallel_maintenance_workers = 4
# --- Оптимизация под 1С:Предприятие ---
from_collapse_limit = 20
join_collapse_limit = 20
escape_string_warning = off
standard_conforming_strings = on2. Проверка выделения Shared Memory ядром Linux
# Убедитесь, что лимиты shared memory в sysctl достаточны
sysctl -w sys.kernel.shmmax=18446744073709551615
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=803. Применение конфигурации без перезапуска сервера
-- Перечитывание параметров, не требующих рестарта инстанса
SELECT pg_reload_conf();
-- Проверка параметров, требующих обязательного рестарта
SELECT name, setting, pending_restart
FROM pg_settings
WHERE pending_restart = true; Частые вопросы (FAQ)
Почему нельзя выделять shared_buffers больше 40% оперативной памяти в Linux?
PostgreSQL полагается на двойное кэширование: собственный буферный пул (shared_buffers) и кэш страниц операционной системы (Page Cache). Избыточный shared_buffers приводит к неэффективному дублированию данных и задержкам на синхронизацию.
Как параметр work_mem может вызвать Out of Memory (OOM)?
work_mem выделяется на каждую операцию сортировки или хеширования внутри плана запроса. Сложный запрос с 5 соединениями может потребовать 5 x work_mem. При 100 активных клиентах суммарный объем может легко превысить физическую память.
Зачем изменять random_page_cost с 4.0 (по умолчанию) до 1.1?
Значение 4.0 рассчитано на медленные HDD со временем поиска головки. На современных SSD/NVMe случайное чтение почти так же быстро, как последовательное, и занижение параметра заставляет планировщик чаще и эффективнее использовать индексы.
Как проверить, какие запросы создают временные файлы на диске?
Включите в postgresql.conf параметр log_temp_files = 0, после чего в логах PostgreSQL будут фиксироваться все запросы, превысившие лимит work_mem.