Работа платформы 1С:Предприятие в клиент-серверном режиме на базе свободной СУБД PostgreSQL — одно из самых популярных и экономически эффективных решений для автоматизации бизнеса. Однако администрирование этой связки требует понимания множества технических нюансов: от выбора правильного дистрибутива до тонкой настройки конфигурационных файлов и устранения аварийных сбоев служб. В этой статье мы подробно разберем все этапы жизненного цикла PostgreSQL в среде 1С, опираясь на практический опыт специалистов и актуальные технологические стандарты.
Прежде всего разберемся в различиях дистрибутивов. На установочных дисках и порталах ИТС часто можно встретить файлы с суффиксами .msi и -int.msi. Обычный установщик ориентирован на стандартную установку СУБД, в то время как версия с суффиксом -int (international) содержит встроенную многоязычную поддержку локалей и кодировок, что критически важно для корректной работы баз данных 1С с русскоязычными кодировками (например, UTF-8 или WIN1251). Всегда выбирайте установщик с маркировкой -int.msi.
Что касается выбора версий: использовать «ванильные» (оригинальные) сборки PostgreSQL напрямую с официального сайта разработчиков СУБД для работы с 1С категорически не рекомендуется. Платформа 1С предъявляет специфические требования к работе с блокировками, индексами и планами запросов. В оригинальном PostgreSQL отсутствуют патчи для корректного сравнения строк в соответствии со стандартами 1С, механизмы работы со временными таблицами и оптимизация сложных вложенных соединений.
Рассмотрим основные варианты дистрибутивов, адаптированных под требования 1С:
Tantor SE 1C, Pangolin от Сбера или Jatoba.Если ваша платформа 1С обновлена до современных версий (8.3.20 и выше), оптимальным выбором станет использование СУБД на базе PostgreSQL 14, 15, 16 или 17. Новейшая 18-я версия PostgreSQL привносит технологический прорыв в виде встроенного асинхронного ввода-вывода (AIO), что значительно ускоряет выполнение планов запросов в облачных средах и на быстрых дисковых массивах.
При переходе со старых версий СУБД (например, с ветки 9.x на 10.x или 11.x и выше) прямая замена исполняемых файлов или использование встроенной утилиты pg_upgrade на операционных системах семейства Windows нередко приводит к скрытым ошибкам индексации и сбоям сопоставления локалей (особенно при работе с буквой «ё» и спецсимволами). Самым надежным и проверенным на практике способом является обновление через промежуточную выгрузку информационных баз.
Проанализируем шаги этой процедуры:
.dt.data в директории установки старого PostgreSQL) на случай экстренного отката.postgres..dt. В процессе загрузки платформа автоматически создаст необходимую структуру таблиц и перестроит индексы в соответствии с требованиями новой версии СУБД.Одной из наиболее частых проблем при эксплуатации PostgreSQL на операционных системах Windows Server является сбой, при котором после перезапуска сервера или аварийного отключения питания служба СУБД переходит в состояние «Остановлена» и отказывается запускаться вручную. При этом в процессах диспетчера задач могут хаотично висеть заброшенные процессы postgres.exe.
Выясним причину этой проблемы. Обратимся к системному журналу событий или лог-файлам PostgreSQL (каталог pg_log). Там мы увидим характерную ошибку:
FATAL: lock file "postmaster.pid" already exists. HINT: Is another postmaster (PID) running in data directory?
Блокировочный файл postmaster.pid создается сервером при запуске и служит индикатором того, что копия СУБД уже активна в данном каталоге данных. При корректном выключении этот файл автоматически удаляется. Однако при аварийном завершении работы системы (или жестком «прибивании» процессов администратором) файл остается на диске, блокируя все последующие попытки старта службы.
Разберем по шагам, как исправить эту ситуацию:
postgres.exe.D:\PostgreData или C:\Program Files\PostgreSQL\...\data).postmaster.pid и удалите его вручную. Внимание! Удаляйте этот файл только убедившись, что все процессы СУБД полностью остановлены, иначе вы рискуете повредить активную базу данных.services.msc. СУБД автоматически проведет процедуру восстановления транзакций из файлов WAL (журнал упреждающей записи) и перейдет в режим готовности к подключениям.При попытке выполнить резервное копирование крупных баз 1С (особенно конфигураций ERP, КА или УПП с большим объемом метаданных) штатными средствами СУБД (через утилиту pg_dump) администраторы часто сталкиваются со следующей ошибкой:
pg_dump: Dumping the contents of table "config" failed: ERROR: out of shared memory. HINT: You might need to increase max_locks_per_transaction.
Причина кроется в особенностях хранения структуры конфигурации 1С в базе данных. Платформа записывает конфигурационные файлы (метаданные) в таблицу config в виде большого количества двоичных записей (BLOB). При выгрузке этой таблицы утилита резервного копирования запрашивает огромное количество блокировок на транзакцию, превышающее лимиты СУБД по умолчанию.
Чтобы решить эту проблему раз и навсегда, необходимо скорректировать настройки конфигурационного файла postgresql.conf. Откроем этот файл в текстовом редакторе, найдем параметр max_locks_per_transaction и увеличим его значение:
# По умолчанию значение может быть равно 64 или 100
max_locks_per_transaction = 250
После изменения параметра обязательно перезапустите службу PostgreSQL. Это выделит дополнительную разделяемую память под таблицы блокировок и позволит без ошибок выгружать даже самые тяжелые конфигурации 1С.
При установке СУБД из стандартных пакетов 1С встроенный инструмент администрирования pgAdmin 4 при запуске может выдавать ошибку "the application server could not be contacted". Это происходит из-за некорректной конфигурации встроенного веб-сервера утилиты в сборке.
Чтобы не тратить время на сложную перенастройку путей и переменных окружения Python внутри дистрибутива, рекомендуется поступить следующим образом: удалите встроенную утилиту и скачайте актуальную автономную версию pgAdmin 4 с официального сайта разработчиков этого инструмента. Отдельно установленный клиент работает стабильно, не конфликтует со службами СУБД и позволяет комфортно управлять любыми базами данных на сервере.
Параметры PostgreSQL по умолчанию рассчитаны на работу на крайне слабых компьютерах с целью гарантированного запуска СУБД в любых условиях. Для реальной работы предприятия СУБД необходимо настроить под имеющиеся аппаратные ресурсы сервера.
Рассмотрим оптимальный вариант настройки конфигурационного файла postgresql.conf для сервера среднего уровня (например, процессор Intel Core i7 / Xeon с 8–12 ядрами и 16 ГБ оперативной памяти):
# Ограничение на максимальное количество соединений (для небольшого офиса достаточно 50-100)
max_connections = 50
# Объем разделяемой памяти СУБД (рекомендуется выделять около 25% от общего объема ОЗУ)
shared_buffers = 4GB
# Объем памяти для временных буферов
temp_buffers = 256MB
# Лимит памяти на одну операцию сортировки или сложного соединения
work_mem = 128MB
# Память на операции обслуживания (создание индексов, очистка VACUUM)
maintenance_work_mem = 1GB
# Настройка упреждающей записи WAL
wal_sync_method = open_datasync
wal_buffers = 16MB
max_wal_size = 2GB
min_wal_size = 512MB
# Степень агрессивности записи контрольных точек (0.9 размазывает нагрузку на диск)
checkpoint_completion_target = 0.9
# Оценка стоимости произвольного чтения (для SSD дисков ставим 1.1 - 1.5, для HDD оставляем 4.0)
random_page_cost = 1.1
# Оценка доступной кэш-памяти операционной системы (около 50-75% от всей ОЗУ)
effective_cache_size = 12GB
# Максимальное число блокировок на транзакцию (критично для стабильных бэкапов 1С)
max_locks_per_transaction = 250
Если же мы администрируем мощный производительный сервер (ОЗУ 64 ГБ, быстрые диски NVMe SSD, многоядерная архитектура), параметры можно настроить еще более производительно. Обратите внимание на параметры параллелизации, появившиеся в современных версиях СУБД (начиная с PostgreSQL 11):
# Пример конфигурации под ОЗУ 64 ГБ и 12-ядерный процессор с SSD NVMe
shared_buffers = 16GB
temp_buffers = 256MB
work_mem = 512MB
maintenance_work_mem = 2GB
# Включаем параллельное построение индексов и обработку запросов
max_worker_processes = 12
max_parallel_workers_per_gather = 4
max_parallel_maintenance_workers = 4
# Оптимизируем работу дисковой подсистемы NVMe
effective_io_concurrency = 200
random_page_cost = 1.1
effective_cache_size = 48GB
# Безопасное кэширование транзакций (внимание: при отключении синхронного коммита
# есть риск утери данных за последнюю секунду при сбое питания, но скорость возрастает в разы)
synchronous_commit = off
Применение этих настроек позволит сбалансировать нагрузку на дисковую подсистему, эффективно задействовать оперативную память сервера под кэширование таблиц СУБД и значительно поднять общую скорость проведения документов в 1С:Предприятии.