PostgreSQL под 1С: параметры сервера, права и подключение

Сервер 1С работает с PostgreSQL только через правильно подготовленный экземпляр СУБД. Голая установка «из коробки» запустится, но на первой же тяжёлой базе начнёт тормозить: не хватит памяти под кеш, захлебнётся журнал предзаписи, упрутся блокировки. Поэтому после установки обязательно правят два файла — postgresql.conf (производительность) и pg_hba.conf (доступ) — и создают пользователя СУБД с нужными правами.

Ниже — рабочий порядок: что проверить до старта, какие параметры выставить под объём оперативной памяти сервера, как подключить специальные модули под 1С, настроить аутентификацию и обслуживание. Числа даны для ориентира — пересчитайте их под свою память.

Важно использовать сборку PostgreSQL, адаптированную под 1С (патченую версию от 1С или Postgres Pro). Обычный «ванильный» PostgreSQL с 1С официально не поддерживается: часть запросов платформы на нём работает некорректно.

Что проверить до установки сервера СУБД

Сначала определитесь с ресурсами машины и совместимостью версий — ошибка на этом шаге потом всплывёт как необъяснимые тормоза.

• 💾 Оперативная память. Минимум 8 ГБ для небольшой базы, для рабочего сервера — от 16–32 ГБ. PostgreSQL кеширует данные в памяти, и чем её больше, тем меньше обращений к диску.
• 🧩 Сборка PostgreSQL. Берите дистрибутив именно под 1С (патченый PostgreSQL или Postgres Pro). Версию выбирайте не ниже той, что поддерживает ваша версия платформы 8.3.
• 💽 Диск. SSD или NVMe под каталог данных (PGDATA) и отдельно — под журнал WAL, если нагрузка высокая. На HDD крупная база 1С будет упираться в диск.
• 🖥 ОС. Linux (Ubuntu, Debian, RHEL-семейство) или Windows Server 2016 и новее. На Linux PostgreSQL обычно стабильнее и экономнее по памяти.
• 🌐 Сеть. Если сервер 1С и сервер СУБД на разных машинах — между ними должна быть быстрая связь и открытый порт (по умолчанию 5432).

При установке кластер инициализируется в кодировке UTF-8 — это требование 1С. Если устанавливаете из пакетов и инициализируете initdb вручную, проверьте, что локаль и кодировка заданы в UTF-8, иначе платформа не создаст информационную базу.

Память и основные параметры в postgresql.conf

Файл postgresql.conf лежит в каталоге данных кластера (PGDATA). Правьте его любым текстовым редактором, после изменений сервер нужно перезапустить (часть параметров подхватывается через pg_reload_conf(), но память требует рестарта).

Основные параметры считаются от объёма ОЗУ. Ниже — ориентиры для сервера с 32 ГБ памяти, отданной под СУБД:

Пересчёт под свою память простой: shared_buffers — четверть ОЗУ, effective_cache_size — три четверти. Для 16 ГБ это 4GB и 12GB соответственно.

work_mem опасно задирать: он выделяется на каждую операцию в каждом соединении. При work_mem = 64MB и сотне параллельных сложных запросов сервер может запросить несколько гигабайт сверх shared_buffers. Если памяти в обрез — начинайте с 32–64MB и смотрите по нагрузке.

Ещё два параметра, которые заметно влияют на 1С:

• random_page_cost = 1.1 — для SSD/NVMe. На HDD оставьте значение по умолчанию (4). Параметр говорит планировщику, насколько случайное чтение дороже последовательного.
• max_locks_per_transaction = 256 — 1С в одной транзакции захватывает много блокировок (проведение документов по регистрам). Значение по умолчанию 64 часто мало; поднимите до 150–256.

Специальные модули под 1С: online_analyze и plantuner

Это тот шаг, который чаще всего пропускают, — а без него планировщик PostgreSQL строит плохие планы для временных таблиц 1С, и отчёты «необъяснимо» тормозят. В патченых под 1С сборках идут два модуля: online_analyze и plantuner.

Подключаются они в postgresql.conf:

shared_preload_libraries = 'online_analyze, plantuner'

online_analyze.enable = on
online_analyze.table_type = 'temporary'
online_analyze.local_tracking = on
online_analyze.verbose = off
online_analyze.min_interval = 10000
online_analyze.min_gain = 10

plantuner.fix_empty_table = on

Что они дают:

• online_analyze автоматически обновляет статистику по временным таблицам сразу после их заполнения. 1С создаёт временные таблицы постоянно, а без свежей статистики планировщик считает, что в них ноль строк, и выбирает медленный план.
• plantuner с параметром fix_empty_table = on не даёт планировщику считать только что созданную пустую таблицу «вечно пустой».

После рестарта проверьте, что модули загрузились, запросом SHOW shared_preload_libraries; — он должен вернуть обе библиотеки.

Доступ к серверу: правим pg_hba.conf

Файл pg_hba.conf (в том же PGDATA) определяет, кто и откуда может подключаться и каким способом подтверждает пароль. Правило читается сверху вниз, применяется первое подходящее.

Строка состоит из типа подключения, базы, роли, адреса и метода. Чтобы разрешить серверу 1С подключаться из своей подсети по паролю:

# тип   база   роль    адрес             метод
host    all    all     192.168.1.0/24    scram-sha-256

Разберём поля:

• host — подключение по TCP/IP (для локальных Unix-сокетов используется local).
• all / all — любая база и любая роль. Можно сузить до конкретной роли 1С.
• 192.168.1.0/24 — подсеть, из которой разрешён доступ. Укажите адрес сервера 1С.
• scram-sha-256 — метод проверки пароля. Это современный способ; md5 оставляйте только для совместимости со старыми клиентами.

Если сервер 1С и СУБД на одной машине, подключение идёт на 127.0.0.1, добавьте строку с адресом 127.0.0.1/32.

Чтобы сервер вообще слушал сеть, в postgresql.conf должно стоять:

listen_addresses = '*'
port = 5432

После правки pg_hba.conf перезагрузите конфигурацию — полный рестарт не нужен:

pg_ctl reload

Журнал предзаписи WAL и контрольные точки

WAL (Write-Ahead Log, журнал предзаписи) — это механизм, который гарантирует целостность данных: изменения сначала пишутся в журнал, потом применяются к файлам базы. Для 1С с её интенсивной записью настройка WAL прямо влияет на скорость проведения документов.

Основные параметры в postgresql.conf:

wal_level = replica
min_wal_size = 2GB
max_wal_size = 8GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
synchronous_commit = on

Как это работает:

• max_wal_size / min_wal_size задают, сколько места отведено под журнал. Чем больше max_wal_size, тем реже происходят контрольные точки (сброс данных на диск) — и тем ровнее нагрузка. Для нагруженной базы 8–16GB нормально.
• checkpoint_completion_target = 0.9 растягивает запись контрольной точки во времени, чтобы не было пиков нагрузки на диск.
• synchronous_commit = on — безопасный режим: подтверждение транзакции только после записи в журнал. Отключать synchronous_commit ради скорости рискованно: при аварийном выключении потеряете последние зафиксированные транзакции.

Если нужна репликация или регулярный pg_basebackup, оставляйте wal_level = replica. Для одиночного сервера без реплик этого достаточно.

Пользователь СУБД и права для подключения из 1С

Серверу 1С нужна учётная запись PostgreSQL, под которой он создаёт и обслуживает информационные базы. Эта роль должна уметь создавать базы данных и роли — платформа при создании ИБ заводит объекты сама.

Создайте отдельную роль (не используйте общий postgres в продуктивной среде). Подключитесь к серверу под суперпользователем и выполните:

CREATE ROLE usr1cv8 WITH LOGIN
    CREATEDB
    CREATEROLE
    PASSWORD 'надёжный_пароль';

Разберём права:

• LOGIN — роль может подключаться (без него это группа, а не пользователь).
• CREATEDB — право создавать базы. Без него 1С не создаст информационную базу.
• CREATEROLE — право заводить роли; платформа использует его при создании ИБ.

Пароль задавайте сложный: эта учётка имеет широкие права. Менять его потом — командой ALTER ROLE usr1cv8 WITH PASSWORD '...';.

Дальше эти же логин и пароль указываются при создании информационной базы в 1С. В окне добавления ИБ выберите тип СУБД PostgreSQL, затем заполните:

• Сервер баз данных — адрес (или адрес с портом, например 192.168.1.10 или 192.168.1.10 port=5432).
• Имя базы данных — произвольное латиницей, платформа создаст базу под этим именем.
• Пользователь и Пароль — та самая роль usr1cv8.
• Флажок Создать базу данных в случае её отсутствия — чтобы платформа завела базу сама.

Ниже — быстрая диагностика, если подключение не проходит.

Регулярное обслуживание и контроль состояния

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

Автоочистка (autovacuum). Держите её включённой — она чистит «мёртвые» версии строк и обновляет статистику:

autovacuum = on

На очень активных базах 1С имеет смысл сделать autovacuum агрессивнее (чаще запускать, давать больше maintenance_work_mem), но полностью отключать его нельзя — база распухнет.

Статистика планировщика. Если отчёты стали медленнее без видимой причины, обновите статистику вручную:

ANALYZE;

Мониторинг активности. Текущие соединения и запросы видно через системное представление:

SELECT pid, state, query, wait_event
FROM pg_stat_activity
WHERE state <> 'idle';

Для разбора медленных запросов включают расширение pg_stat_statements (добавляется в shared_preload_libraries и создаётся командой CREATE EXTENSION pg_stat_statements;).

Резервные копии. Настройте регулярный бэкап: для небольших баз — pg_dump, для крупных и с точкой восстановления — pg_basebackup вместе с архивированием WAL. Бэкап средствами PostgreSQL снимается без остановки сервера.

Полезно раз в период пересоздавать раздувшиеся индексы REINDEX-ом — но это тяжёлая операция, запускайте её в нерабочее время.

Частые вопросы