Тюнинг параметров PostgreSQL под 1С: shared_buffers, work_mem, connections
- Медленная работа клиент-серверной базы 1С на базе PostgreSQL по сравнению с MS SQL.
- Сброс промежуточных выборок запросов на диск (дисковый spill в
pgsql_tmp). - Высокое потребление RAM процессами
postgres: client backendи риск срабатывания Linux OOM Killer. - Ошибки
sorry, too many clients already.
1. Базовый расчет ключевых параметров в postgresql.conf
# Память (для выделенного сервера с 64GB RAM под СУБД)
shared_buffers = 16GB # 25% от общей RAM
effective_cache_size = 48GB # 70-75% от общей RAM
work_mem = 64MB # Память на одну операцию сортировки
maintenance_work_mem = 2GB # Память для вакуума и индексов
temp_buffers = 32MB # Временные буферы сессии
# Соединения
max_connections = 300 # Зависит от количества рабочих процессов rphost
# Контрольные точки (Checkpoints) и WAL
checkpoint_completion_target = 0.9
min_wal_size = 4GB
max_wal_size = 16GB
wal_buffers = 16MB
# Планировщик под специфику сборки PostgreSQL для 1С
random_page_cost = 1.1 # Для NVMe/SSD дисков (4.0 для HDD)
seq_page_cost = 1.0
effective_io_concurrency = 200
# Блокировки и тайминги
max_locks_per_transaction = 256
from_collapse_limit = 20
join_collapse_limit = 202. Применение настроек
sudo systemctl restart postgresql-14 # или pg_ctl reload для динамических параметров3. Проверка попадания в кэш (Cache Hit Ratio)
SELECT
sum(heap_blks_read) as heap_read,
sum(heap_blks_hit) as heap_hit,
(sum(heap_blks_hit) - sum(heap_blks_read)) / sum(heap_blks_hit) * 100 as ratio
FROM pg_statio_user_tables; Частые вопросы (FAQ)
Почему shared_buffers в PostgreSQL для 1С не стоит делать больше 25-30% RAM?
PostgreSQL полагается на двойное кэширование: собственный буфер shared_buffers и Page Cache операционной системы Linux. Выделение свыше 30-40% часто ухудшает производительность из-за двойной нагрузки на сборщик мусора.
Чем опасен слишком большой параметр work_mem?
work_mem выделяется на каждую операцию сортировки/хэширования внутри одного запроса. Если сложный запрос выполняет 5 сортировок в 100 параллельных сессиях, память может мгновенно закончиться, вызвав OOM Killer.
Зачем нужны параметры from_collapse_limit = 20 и join_collapse_limit = 20?
Платформа 1С генерирует сложные запросы с большим количеством вложенных соединений. Значения по умолчанию (8) заставляют планировщик переставать оптимизировать порядок JOIN, что ведет к катастрофическим планам.
Какую версию PostgreSQL использовать для 1С?
Необходимо использовать специализированные сборки с патчами для 1С (Postgres Pro 1C или официальные сборки от фирмы «1С»), так как стандартный ванильный PostgreSQL некорректно работает со структурой метаданных 1С.