Развертывание и тонкая настройка СУБД PostgreSQL для работы с платформой «1С:Предприятие 8» — одна из ключевых задач системного администрирования. Рекомендации, которые были актуальны во времена версий PostgreSQL 9.2–9.6, сегодня не просто устарели, а могут нанести прямой вред производительности и стабильности современной информационной системы. Технологии не стоят на месте: изменились механизмы самой платформы 1С, претерпела архитектурные изменения СУБД PostgreSQL (вплоть до актуальных версий 15, 16 и 17), а также появились специализированные сборки СУБД от компании Postgres Professional и фирмы 1С.
В этой статье мы подробно рассмотрим, как правильно настроить современные версии PostgreSQL для работы с 1С, разберем ключевые конфигурационные параметры, развенчаем опасные мифы администрирования и выработаем оптимальный шаблон настроек для высоконагруженных систем.
Исторически многие администраторы 1С предпочитали разворачивать PostgreSQL на ОС семейства Windows из-за простоты обслуживания. Однако, как показывает практика и многочисленные тесты производительности (включая нагрузочные тесты и реальные сценарии закрытия месяца в тяжелых конфигурациях уровня ERP), PostgreSQL под Windows работает существенно медленнее и менее стабильно, чем на Linux.
Причины кроются в архитектурных особенностях СУБД. PostgreSQL изначально проектировался под POSIX-совместимые операционные системы. Механизмы управления процессами, выделения общей памяти (Shared Memory), работы с дисковым кэшем и планировщиком ввода-вывода в Linux реализованы значительно эффективнее. На Windows СУБД вынуждена использовать эмуляцию некоторых системных вызовов, что создает дополнительные накладные расходы на процессоре и дисковой подсистеме.
Рекомендация: Для продуктивных (рабочих) баз данных 1С используйте исключительно Linux-дистрибутивы (например, Astra Linux, ALT Linux, Red OS, Ubuntu Server или Debian). Развертывание PostgreSQL на Windows допускается только для серверов разработки или небольших тестовых контуров. Для этой задачи можно использовать сценарий автоматизации установки PostgreSQL и 1С в Astra Linux.
В сообществе администраторов 1С до сих пор бытует вредный совет: «Отключите autovacuum в postgresql.conf, а очистку (VACUUM; ANALYZE) запускайте вручную ночью по планировщику (cron)». Мотивируют это тем, что фоновый процесс очистки якобы создает избыточную нагрузку на диски и процессор в рабочее время.
Рассмотрим подробнее, почему следование этому совету гарантированно приведет к деградации производительности:
Выясним правильный подход: автовакуум отключать категорически запрещено. Вместо отключения его необходимо настроить более агрессивно, чтобы он успевал обрабатывать измененные данные небольшими порциями, не создавая пиковых нагрузок.
Проанализируем оптимальные параметры настройки автовакуума:
autovacuum = on
autovacuum_max_workers = 4 # Увеличьте до 6-8, если у вас более 32 ядер CPU
autovacuum_naptime = 20s # Интервал обхода таблиц демоном очистки
autovacuum_vacuum_scale_factor = 0.01 # Запускать очистку при изменении 1% строк в таблице
autovacuum_analyze_scale_factor = 0.005 # Запускать сбор статистики при изменении 0.5% строк
autovacuum_vacuum_cost_limit = 2000 # Увеличивает лимит емкости операций за один проход
autovacuum_vacuum_cost_delay = 2ms # Снижает задержку между циклами очистки
В старых версиях PostgreSQL для 1С активно применялся сторонний модуль online_analyze. Его задачей было мгновенное обновление статистики для временных таблиц сразу после их создания и наполнения данными. Это исключало ситуации, когда планировщик PostgreSQL строил неверный план выполнения тяжелого запроса, считая, что во временной таблице содержится 0 или 1 строка (хотя фактически там могли быть десятки тысяч строк).
Важное изменение: Начиная с версии платформы 1С:Предприятие 8.3.13, разработчики фирмы 1С внедрили встроенный механизм принудительного вызова команды ANALYZE непосредственно после записи данных в созданную временную таблицу на уровне ядра платформы.
Использование модуля online_analyze.enable = on совместно с современными версиями 1С приводит к двойному анализу одной и той же таблицы, что создает паразитную нагрузку на процессор и замедляет выполнение транзакций. Поэтому в современных конфигурационных файлах данный параметр следует отключать или вообще исключать этот плагин из загрузки:
# online_analyze использовать больше не нужно!
online_analyze.enable = off
В рекомендациях для старых версий PostgreSQL (до 14-й включительно) ключевым пунктом оптимизации производительности дисковой подсистемы был перенос каталога временной статистики СУБД pg_stat_temp на RAM-диск (tmpfs в Linux). Статистика обновлялась постоянно, порождая непрерывный поток мелких операций записи на жесткий диск или SSD, что снижало общий ресурс накопителей и замедляло работу.
Начиная с версии PostgreSQL 15, подсистема сбора статистики была полностью переписана разработчиками СУБД. Теперь все статистические данные хранятся и обрабатываются непосредственно в общей оперативной памяти (Shared Memory).
Параметр pg_stat_temp полностью удален из СУБД и больше не поддерживается. Администраторам больше не нужно тратить время на настройку виртуальных RAM-дисков для файлов статистики.
Специфика работы платформы 1С такова, что в процессе выполнения бизнес-логики (например, распределение затрат при закрытии месяца в ERP) создается, заполняется и удаляется колоссальное количество временных таблиц. Каждое создание временной таблицы приводит к записи информации о ней в системный каталог СУБД (метаданные), который физически хранится на диске. Это приводит к сильному износу дисков и блокировкам системного каталога СУБД.
В специализированных сборках PostgreSQL для 1С (начиная с 15-й версии) появился уникальный оптимизационный параметр enable_temp_memory_catalog. При его включении метаданные временных таблиц хранятся только в оперативной памяти:
enable_temp_memory_catalog = on
Включение этого параметра существенно разгружает дисковую подсистему и ускоряет работу с временными таблицами в разы, что особенно критично для крупных баз данных ERP и УПП.
Рассмотрим сбалансированный конфигурационный файл для сервера СУБД под управлением Linux, обладающего следующими характеристиками: 8-16 ядер CPU, 64 ГБ оперативной памяти и быстрые SSD/NVMe диски. Проанализируем настройки по шагам:
# === Сетевые настройки и подключения ===
max_connections = 500 # Платформа 1С активно плодит пул соединений
superuser_reserved_connections = 10
# === Выделение оперативной памяти ===
shared_buffers = 16GB # Рекомендуется выделять около 25% от всей ОЗУ сервера
effective_cache_size = 48GB # Оценка доступного кэша ОС (около 75% от всей ОЗУ)
work_mem = 128MB # Память для сортировок одного запроса. Не завышайте критично!
maintenance_work_mem = 2GB # Память для обслуживания (индексы, vacuum)
temp_buffers = 128MB # Объем памяти под временные таблицы одного сеанса
# === Настройки записи и WAL (Журнал предзаписи) ===
wal_level = replica
synchronous_commit = off # Выключение синхронной фиксации дает кратный прирост скорости
wal_buffers = 16MB
max_wal_size = 16GB
min_wal_size = 4GB
checkpoint_completion_target = 0.9
checkpoint_timeout = 15min
# === Оценка стоимости планировщика (Ориентировано на быстрые SSD/NVMe) ===
seq_page_cost = 0.1 # Стоимость последовательного чтения страницы
random_page_cost = 0.1 # Стоимость случайного чтения (для SSD ставим равной seq)
cpu_operator_cost = 0.002
cpu_tuple_cost = 0.01
effective_io_concurrency = 200 # Для SSD дисков
# === Блокировки ===
max_locks_per_transaction = 512 # Предотвращает ошибки нехватки блокировок при тяжелых запросах 1С
# === Настройки автовакуума ===
autovacuum = on
autovacuum_max_workers = 4
autovacuum_naptime = 20s
autovacuum_vacuum_scale_factor = 0.01
autovacuum_analyze_scale_factor = 0.005
autovacuum_vacuum_cost_limit = 1500
autovacuum_vacuum_cost_delay = 2ms
# === Специфичные настройки для 1С (в зависимости от сборки СУБД) ===
escape_string_warning = off
standard_conforming_strings = off
enable_temp_memory_catalog = on # Хранение метаданных временных таблиц в ОЗУ
Если у вас нет глубокого понимания каждого параметра или вы боитесь допустить ошибку при ручном редактировании postgresql.conf, в современных коммерческих и сертифицированных сборках СУБД (например, Postgres Pro Standard/Enterprise) предусмотрен отличный инструмент автоматической оптимизации — утилита pgpro_tune.
Данная утилита самостоятельно сканирует аппаратные ресурсы сервера (количество ядер, объем ОЗУ, производительность дисковой подсистемы) и на основе встроенных алгоритмов и профилей формирует оптимальный конфигурационный файл для работы СУБД в связке с 1С.
Для оптимизации сервера достаточно запустить утилиту в консоли Linux с указанием профиля 1С:
pgpro_tune --profile 1c --optimize
После этого утилита внесет необходимые корректировки в конфигурационные файлы СУБД, и вам останется только перезапустить службу PostgreSQL для применения изменений.
Правильная настройка современных версий PostgreSQL под 1С требует понимания изменений в архитектуре как самой СУБД, так и платформы «1С:Предприятие 8». Откажитесь от устаревших рекомендаций эпохи версий 9.2–9.6. Никогда не отключайте автовакуум, переходите на операционную систему Linux, используйте преимущества современных версий PostgreSQL (такие как отказ от pg_stat_temp и использование параметра enable_temp_memory_catalog), и ваша система покажет отличную производительность и высокую стабильность работы.