Настройка PostgreSQL для 1С на Linux: параметры, обслуживание и типичные ошибки

Настройка PostgreSQL для 1С сводится к четырём вещам: поставить сборку СУБД с патчами для 1С, правильно инициализировать кластер (локаль ru_RU.UTF-8), выставить параметры памяти и подключений под реальную нагрузку и наладить обслуживание — autovacuum, статистику, мониторинг и резервное копирование. Стандартный postgresql.conf «из коробки» рассчитан на минимальное железо, поэтому без настройки база 1С на PostgreSQL почти всегда работает медленнее, чем могла бы.

Ниже — порядок, которым я пользуюсь при развёртывании PostgreSQL на Linux под «1С:Предприятие 8»: что важно при установке, какие параметры трогать в первую очередь и как разбирать частые ошибки. Установку самого сервера 1С и кластера я разбирал отдельно в статье про сервер 1С на Ubuntu, здесь фокус на СУБД.

Зачем связка PostgreSQL и Linux для 1С

PostgreSQL официально поддерживается платформой 1С много лет, а Linux давно стал нормальной серверной ОС для 1С. Причины, по которым компании выбирают эту связку:

Минус один, но существенный: связка требует квалификации. Ошибки, которые на MS SQL «прощались» настройками по умолчанию, на PostgreSQL проявляются ростом базы, медленными запросами и неожиданными блокировками.

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

Какую сборку и версию выбрать

Обычный PostgreSQL из репозитория дистрибутива для 1С не подходит: платформе нужны доработки, которые есть в специальных сборках. Варианты:

• сборка PostgreSQL от фирмы «1С» — распространяется через портал 1С;
• Postgres Pro для 1С — от компании Postgres Professional, ставится из их репозитория (подключается скриптом с сайта вендора), есть варианты для разных версий PostgreSQL.

Главное правило: версия СУБД должна входить в список поддерживаемых для вашей версии платформы. Смотрите его на сайте 1С перед установкой, а не после: новая мажорная версия PostgreSQL может не поддерживаться старой платформой.

Минимум по железу для небольшой рабочей базы — 8 ГБ ОЗУ, SSD и многоядерный процессор. Для десятков пользователей и учётных систем уровня ERP памяти нужно кратно больше.

Установка и инициализация кластера

Последовательность установки на Ubuntu или Debian:

1. Подключите репозиторий выбранной сборки по инструкции вендора и установите пакет СУБД.
2. Проверьте, что в системе есть русская локаль UTF-8:

locale -a | grep ru_RU
# если локали нет:
sudo locale-gen ru_RU.UTF-8

1. Инициализируйте кластер с нужной локалью и контрольными суммами страниц. Многие сборки делают это скриптом установки; если инициализируете вручную, команда выглядит так (путь к initdb и каталог данных зависят от сборки):

initdb -D /var/lib/pgpro/1c-16/data \
  --data-checksums \
  --encoding=UTF8 \
  --locale=ru_RU.UTF-8 \
  --lc-messages=C

1. Включите службу в автозагрузку и проверьте, что она запущена:

sudo systemctl enable --now <имя-службы-postgresql>
sudo systemctl status <имя-службы-postgresql>

Локаль кластера задаётся при инициализации и потом не меняется. Если кластер создан в локали C или en_US, сортировка строк в 1С будет неверной, и это лечится только пересозданием кластера с выгрузкой и загрузкой данных. Поэтому проверяю локаль до создания первой базы.

--data-checksums позволяет СУБД обнаруживать повреждения страниц на диске. Небольшие накладные расходы того стоят: битую страницу лучше увидеть сразу, а не при следующем закрытии месяца.

Сетевой доступ: pg_hba.conf и listen_addresses

Если сервер 1С и СУБД стоят на разных машинах, нужно открыть два места.

В postgresql.conf — на каких адресах слушать:

listen_addresses = '*'        # или конкретный IP сервера СУБД
port = 5432

В pg_hba.conf — кому разрешено подключаться. Разрешайте только подсеть или адреса серверов 1С, а не весь мир:

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

Метод scram-sha-256 надёжнее устаревшего md5; убедитесь, что пароль пользователя задан после включения этого метода. Изменения pg_hba.conf применяются перезагрузкой конфигурации (systemctl reload), а listen_addresses — только перезапуском.

Параметры postgresql.conf для 1С

Свои значения я дописываю в конец postgresql.conf или выношу в отдельный файл через include — так сразу видно, что меняли относительно умолчаний. Ниже — отправные точки для выделенного сервера СУБД. Это ориентиры, а не готовый рецепт: финальные значения подбираются по мониторингу.

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

Сборки Postgres Pro умеют подбирать часть параметров автоматически при инициализации; результат всё равно стоит проверить глазами.

После изменения параметров, требующих перезапуска (shared_buffers, max_connections), перезапустите службу. Остальные применяются через SELECT pg_reload_conf();.

Обслуживание: autovacuum, статистика, бэкапы

PostgreSQL хранит старые версии строк до очистки (механизм MVCC). Если autovacuum не успевает, таблицы «пухнут», индексы деградируют, а статистика устаревает — запросы 1С начинают выбирать плохие планы.

Что я настраиваю на рабочих базах:

• Агрессивный autovacuum для больших таблиц. Уменьшаю autovacuum_vacuum_scale_factor и autovacuum_analyze_scale_factor, чтобы крупные регистры очищались и анализировались чаще, а не после изменения 20% строк.
• Достаточно воркеров. autovacuum_max_workers увеличиваю, если баз и больших таблиц много.
• Плановое обслуживание. Регулярный ANALYZE после массовых загрузок, REINDEX по необходимости. VACUUM FULL — только точечно и в окно обслуживания: он берёт эксклюзивную блокировку таблицы.
• Резервное копирование. Для небольших баз хватает pg_dump по расписанию, для крупных — физические копии с архивом WAL (pg_basebackup, pgBackRest, Barman), что даёт восстановление на момент времени. Подробнее про стратегии — на странице услуги резервное копирование 1С.

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

Мониторинг и поиск медленных запросов

Без мониторинга любая настройка — гадание. Минимальный набор:

• расширение pg_stat_statements — какие запросы в сумме съедают больше всего времени;
• auto_explain или log_min_duration_statement — планы и тексты запросов дольше заданного порога;
• метрики сервера и СУБД в Zabbix или связке Prometheus + Grafana: CPU, память, диски, число подключений, размер баз, отставание autovacuum.

Подключение pg_stat_statements:

# postgresql.conf
shared_preload_libraries = 'pg_stat_statements'

CREATE EXTENSION IF NOT EXISTS pg_stat_statements;

SELECT calls, round(total_exec_time) AS total_ms, left(query, 120) AS query
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 20;

Тексты запросов будут в терминах таблиц СУБД (_Document123, _AccumRg456). Сопоставить их с объектами 1С помогает функция ПолучитьСтруктуруХраненияБазыДанных() или технологический журнал. Если проблема упирается в код конфигурации, а не в СУБД, имеет смысл аудит производительности 1С целиком.

Отдельный кластер PostgreSQL на каждую крупную базу 1С — разумный приём: проще настраивать параметры, обслуживать и восстанавливать. Для пары небольших баз это избыточно.

Типичные ошибки и что с ними делать

Про пул соединений: сервер 1С сам держит пул подключений к СУБД, и внешние пулеры вроде pgbouncer в режиме транзакций ломают работу 1С с временными таблицами и сеансовыми настройками. Для подключений самой платформы я их не использую; pgbouncer уместен для сторонних клиентов — BI, интеграций, отчётных сервисов.

Если нужна помощь с развёртыванием или «лечением» уже работающей связки, это мой регулярный формат работ — 1С на Linux и PostgreSQL.

Итог

• Для 1С нужна специальная сборка PostgreSQL, совместимая с вашей версией платформы.
• Локаль ru_RU.UTF-8 задаётся при инициализации кластера и потом не меняется — проверяйте её до создания баз.
• Параметры памяти и подключений подбираются под нагрузку: начните с ориентиров и уточняйте по мониторингу.
• Autovacuum, статистика и проверенные бэкапы важнее любой «магической» настройки.
• Медленные запросы ищите через pg_stat_statements и auto_explain, а взаимоблокировки — в коде конфигурации.