Настройка PostgreSQL для 1С на сервере с Xeon Gold и 512 ГБ RAM

При развёртывании PostgreSQL для работы с 1С на мощном оборудовании критически важна правильная настройка как гипервизора, так и самой базы данных. В этой статье мы разберём конфигурацию сервера с двумя Xeon Gold 6354 (72 ядра), 512 ГБ оперативной памяти и быстрыми SSD в RAID10, а также параметры postgresql.conf, которые позволили добиться результата теста Гилева в 6,43 единицы (против 113 на файловой базе).

Аппаратная конфигурация и гипервизор

Наш стенд построен на базе Proxmox. Виртуальной машине выделено 18 ядер (режим host), 260 ГБ ОЗУ и диски на SSD-массиве RAID10. Обратите внимание на ключевые параметры VM:

• CPU: режим host (полная эмуляция инструкций хоста)
• Balloon: отключён (0) - память не возвращается гипервизору
• BIOS: OVMF (UEFI) для поддержки современных ОС
• SCSI: virtio-scsi-single с io_uring и writeback - оптимально для высоких нагрузок

Основные настройки PostgreSQL (postgresql.conf)

Конфигурация базы данных заточена под 1С: платформа чувствительна к кешированию данных и параллельным запросам. Рассмотрим важнейшие блоки.

Память и кеш

shared_buffers = 64 ГБ (25% от 256 ГБ, выделенных VM). Это основной кеш страниц данных. Для 1С рекомендуется диапазон 25-40%. work_mem = 512 МБ - память для сортировок и хэшей на один запрос. effective_cache_size = 192 ГБ - подсказка планировщику о размере файлового кеша ОС.

Параллелизм

Поскольку 1С активно использует параллельные запросы (особенно в отчётах), мы задаём:

• max_worker_processes = 18 (по числу ядер)
• max_parallel_workers = 18
• max_parallel_workers_per_gather = 4 - ограничение на один запрос
• max_parallel_maintenance_workers = 4 - для VACUUM и индексов

JIT отключён (jit = off), так как 1С не выигрывает от JIT-компиляции.

Журнал WAL и контрольные точки

Для быстрых SSD (4 ТБ в RAID10) используем агрессивные настройки:

• checkpoint_timeout = 5 минут
• checkpoint_completion_target = 0,9 - растягиваем запись на 90% интервала
• max_wal_size = 4 ГБ, min_wal_size = 2 ГБ
• commit_delay = 1000 мкс - группировка коммитов

Планировщик и стоимость ввода-вывода

Для SSD задаём random_page_cost = 1.1 (чуть выше seq_page_cost = 1.0), что заставляет планировщик предпочитать индексные сканирования. plan_cache_mode = force_custom_plan - для 1С это даёт более стабильные планы.

Автовакуум и обслуживание

1С генерирует много мёртвых кортежей, поэтому автовакуум настроен агрессивно:

• autovacuum_max_workers = 9
• autovacuum_naptime = 20 секунд
• autovacuum_vacuum_scale_factor = 0.01 (1% изменений - запуск)
• autovacuum_analyze_scale_factor = 0.005
• autovacuum_vacuum_cost_limit = 900 - снимаем ограничения по скорости

Статистика и логирование

Включён сбор статистики с расширениями plantuner и online_analyze. Последний особенно полезен для временных таблиц, которые активно использует 1С. Параметры online_analyze.threshold = 50 и online_analyze.scale_factor = 0.1 гарантируют актуальную статистику без задержек.

Результаты теста Гилева

После применения описанной конфигурации тест Гилева на файловой базе показал 113 единиц, а на PostgreSQL - 6,43 единицы. Это означает, что база данных обрабатывает запросы в 17 раз быстрее файлового варианта. Ключевые факторы успеха: правильный расчёт shared_buffers, агрессивный параллелизм и оптимизация под SSD.

Для достижения аналогичных результатов на вашем сервере подбирайте shared_buffers под доступную память, не забывайте про online_analyze и обязательно тестируйте с реальной нагрузкой 1С.