Настройка PostgreSQL под 1С: расчёт для сервера с 32 ГБ ОЗУ

На сервере 32 ГБ памяти, а документы в 1С проводятся медленно. Администратор ставит work_mem = 256MB, перезапускает PostgreSQL — и получает ещё больше обращений к дискам: при 200 соединениях память выделяется не на сервер целиком, а отдельным операциям запросов.

Прежде чем закладывать новый Dell PowerEdge в бюджет, настройте четыре блока: память, оценку стоимости дисковых операций, WAL и autovacuum. Затем повторите одни и те же запросы под нагрузкой. Так Вы отделите нехватку железа от ошибки в postgresql.conf.

Ниже — стартовая конфигурация для выделенного сервера PostgreSQL с 32 ГБ ОЗУ, восемью физическими ядрами, 200 соединениями и SSD. Это не готовый файл для копирования в продакшен: значения нужно проверить на копии базы или в согласованное окно обслуживания.

Память: четыре параметра вместо случайного тюнинга #

Для начала распределим 32 ГБ между кэшем PostgreSQL и рабочей памятью запросов.

shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 32MB
maintenance_work_mem = 1GB

shared_buffers получает четверть физической памяти. Такую пропорцию задаёт методика «Настройки PostgreSQL для работы с 1С:Предприятием» на портале 1С:ИТС:

32 ГБ / 4 = 8 ГБ

effective_cache_size не резервирует 24 ГБ. Параметр сообщает планировщику, какой объём данных может находиться в кэше PostgreSQL и операционной системы. По формуле 1С:

32 ГБ − 8 ГБ shared_buffers = 24 ГБ

С work_mem опаснее. PostgreSQL может выделить этот объём нескольким сортировкам и хеш-операциям внутри одного запроса. Поэтому умножать 256MB на число соединений недостаточно: один запрос способен запросить память несколько раз.

Для исходных 200 соединений применим формулу из практической методики настройки PostgreSQL под 1С:

(32 ГБ − 8 ГБ) / (200 × 4) = 30,72 МБ

Округляем до 32MB. При 100 соединениях расчёт даст около 61 МБ — можно начать с 64MB. Правило переноса простое: чем выше max_connections, тем меньше безопасный общий work_mem.

maintenance_work_mem = 1GB используют операции обслуживания: VACUUM, CREATE INDEX и REINDEX. Это стартовое значение из конфигурации на 32 ГБ, приведённой в той же практической методике. Если перестроение индекса вытесняет рабочие данные или система уходит в swap, уменьшайте его.

Когда PostgreSQL делит сервер с 1С #

На совмещённом сервере считать от всех 32 ГБ нельзя. Процессы rphost, операционная система, антивирус и агенты резервного копирования тоже требуют память.

Практическая методика рекомендует оставлять PostgreSQL до половины физической ОЗУ, когда рядом работает сервер приложений 1С. Если базе достаются 16 ГБ, расчёт меняется:

shared_buffers = 4 ГБ
work_mem = (16 − 4) ГБ / (200 × 4) ≈ 15 МБ

Начните с work_mem = 16MB, а не с 32 или 256 МБ. Параметры процессов платформы считайте отдельно: они разобраны в материале о настройке рабочего сервера 1С.

SSD не поможет, если планировщик считает его медленным #

PostgreSQL выбирает между последовательным чтением таблицы и обращением по индексу. На этот выбор влияет random_page_cost: чем он выше, тем дороже планировщик считает случайное чтение.

Для SSD методика 1С задаёт диапазон 1.1–1.3, для RAID — 1.5–2.0:

random_page_cost = 1.2

1.2 — середина стартового диапазона, а не обязательное значение. После изменения сравните план и время одного и того же тяжёлого запроса. Если раньше в плане был Seq Scan, а после появился Index Scan и снизился IO:Timing, параметр влиял на задержку.

Параметр effective_io_concurrency зависит от накопителей. Практическая методика даёт такие отправные точки:

# SATA SSD
effective_io_concurrency = 100

# NVMe
effective_io_concurrency = 200

# HDD
effective_io_concurrency = 2

Не меняйте накопители только из-за одного медленного запроса. Сначала соберите его план и время через pg_stat_statements, встроенный мониторинг 1С или технологический журнал 1С для PostgreSQL. Если задержка возникла внутри кода 1С, более быстрый NVMe сократит дисковую часть, но не исправит сам запрос.

WAL: не покупайте скорость ценой документов #

Оставьте fsync = on. По методике 1С этот параметр синхронизирует данные с диском и защищает целостность базы при сбое:

fsync = on
synchronous_commit = on

synchronous_commit = off сокращает ожидание записи WAL. Цена — последние транзакции при аварийном отключении. Методика 1С оценивает возможное окно потери в 0,5–1 секунду.

Для бухгалтерской базы такой обмен обычно не оправдан: пользователь увидел проведённый документ, а после сбоя его нет. Отключать синхронную фиксацию можно лишь там, где потеря последних операций заранее допустима и описана в требованиях к системе.

Для PostgreSQL 9.5 и новее 1С приводит стартовые диапазоны:

min_wal_size = 512MB
max_wal_size = 1GB
checkpoint_completion_target = 0.9

max_wal_size здесь вдвое больше min_wal_size. При интенсивной записи диапазон min_wal_size можно увеличивать вплоть до 4 ГБ, но только после наблюдения за частотой checkpoints и объёмом WAL.

Параметр checkpoint_segments в современный файл переносить не нужно. Методика 1С относит его к версиям PostgreSQL ниже 9.5.

Autovacuum: замедление приходит через несколько недель #

Не отключайте autovacuum, даже если его процессы видны в момент нагрузки. Он удаляет устаревшие версии строк и обновляет статистику, без которой таблицы разрастаются, а планировщик начинает ошибаться.

Для восьми физических ядер стартовый блок выглядит так:

autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02

1С рекомендует рассчитывать число workers от количества ядер, но ограничивает обычную конфигурацию четырьмя процессами. Интервал запуска — 20 секунд; практическая методика допускает старт с 30 секунд.

Если таблицы продолжают расти, уменьшите autovacuum_vacuum_scale_factor до 0.01–0.05. Увеличивать autovacuum_max_workers до шести стоит лишь после подтверждённого отставания очистки: дополнительные процессы конкурируют с рабочими запросами за CPU и диски.

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

Стартовый набор для 32 ГБ, восьми ядер и SSD #

Для выделенного сервера PostgreSQL с 200 соединениями начните с такого набора:

shared_buffers = 8GB
effective_cache_size = 24GB
work_mem = 32MB
maintenance_work_mem = 1GB

random_page_cost = 1.2
effective_io_concurrency = 100 # SATA SSD
# effective_io_concurrency = 200 # NVMe

fsync = on
synchronous_commit = on

min_wal_size = 512MB
max_wal_size = 1GB
checkpoint_completion_target = 0.9

autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.05
autovacuum_analyze_scale_factor = 0.02

Не меняйте весь блок за один перезапуск. Сначала сохраните планы, среднее время и IO:Timing тяжёлых запросов. Затем меняйте по одному блоку: память, параметры дисков, WAL, autovacuum. После каждого изменения повторяйте одинаковую нагрузку через pgbench и средства наблюдения 1С.

Если после настройки сохраняется высокий IO:Timing, переходите к подбору сервера для PostgreSQL. Там уже есть предмет для бюджета: производительность одного ядра, объём RDIMM, тип SSD, RAID-контроллер и запас дисковых отсеков.

Если задержка остаётся в процессах 1С, новый Dell PowerEdge может дать слабый эффект. Сначала исправьте лимиты rphost, распределение сеансов и проблемные запросы. Покупку сервера согласовывайте после замера: время запроса до и после настройки, загрузка CPU, использование памяти и дисковая задержка. Без этих четырёх показателей сумма в рублях будет догадкой.