Переход на связку 1С и PostgreSQL часто сопровождается техническими сложностями, особенно если администратор привык к работе с MS SQL Server. Одной из наиболее острых проблем является нестабильность рабочих процессов сервера 1С (rphost) и неожиданные разрывы соединений при выполнении тяжелых операций, таких как загрузка информационной базы из файла выгрузки .dt. В рамках данной статьи мы детально разберем, как подобрать стабильную связку версий, правильно настроить параметры СУБД и избежать критических ошибок памяти.
Опыт эксплуатации различных версий показывает, что «новейшая» версия не всегда означает «самая стабильная». Разберем проверенные сообществом варианты, которые зарекомендовали себя в промышленной эксплуатации:
8.3.14.1993 в сочетании с PostgreSQL 11.5. Эта связка считается одной из самых предсказуемых для систем, не требующих функционала последних релизов.8.3.15.1830 или 8.3.18.1957. В качестве СУБД рекомендуется использовать специализированные сборки Postgres Pro (версии 13 или 14), которые включают патчи, оптимизирующие работу с блокировками и полнотекстовым поиском 1С.8.3.16 (в частности, сборка 1030), так как в ней были зафиксированы ошибки, приводящие к утечкам памяти в рабочих процессах и некорректному завершению транзакций при обмене данными с PostgreSQL.Проанализируем типичную ситуацию: сервер падает при загрузке базы объемом 1.5 ГБ из .dt. Ошибка в логах An existing connection was forcibly closed by the remote host часто указывает на то, что процесс rphost был принудительно завершен операционной системой или самим менеджером кластера.
Основная причина здесь кроется в использовании 32-битного сервера приложений 1С. Рассмотрим, почему это критично:
.dt файла платформа создает в оперативной памяти сложные структуры данных. Если объем временных данных превышает лимит процесса, происходит Access Violation, и сервер падает.rphost.Для того чтобы СУБД выдерживала нагрузки при загрузке данных и массовых операциях, стандартных настроек «из коробки» недостаточно. Выясним, какие параметры требуют корректировки в первую очередь:
1. Параметры записи (WAL):
Параметр max_wal_size определяет максимальный размер логов транзакций между контрольными точками. Для баз среднего размера рекомендуется установить значение не менее 4GB.
# В файле postgresql.conf
max_wal_size = 4GB
min_wal_size = 1GB
checkpoint_timeout = 15min
2. Память для обслуживания:
При загрузке данных из .dt активно создаются индексы. За это отвечает параметр maintenance_work_mem. Его стоит временно увеличить, чтобы ускорить процесс и избежать лишних дисковых операций.
maintenance_work_mem = 512MB # Или 1GB, если позволяет ОЗУ
3. Отключение синхронизации (только для загрузки):
Если вам нужно максимально быстро развернуть базу из .dt и вы готовы рискнуть целостностью данных в случае внезапного отключения питания, можно временно отключить fsync. Важно: после успешной загрузки обязательно верните значение в on.
fsync = off # ТОЛЬКО НА ВРЕМЯ ЗАГРУЗКИ
Если сервер продолжает падать, а логи PostgreSQL не дают ясного ответа, необходимо проанализировать работу самой платформы 1С. Для этого настроим Технологический журнал (ТЖ), создав файл logcfg.xml в каталоге conf сервера 1С.
Рассмотрим пример настройки для отслеживания аварийных завершений (события EXCP и PROC):
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\1C" history="24">
<event>
<eq property="Name" value="EXCP"/>
</event>
<event>
<eq property="Name" value="PROC"/>
</event>
<property name="all"/>
</log>
</config>
После падения сервера проанализируем созданные файлы логов. В них можно найти конкретный метод или таблицу, на которой процесс rphost исчерпал ресурсы или получил системную ошибку.
Если ваш PostgreSQL развернут на ОС Linux, причиной ошибки connection closed может быть работа механизма OOM Killer (Out of Memory Killer). Когда оперативной памяти становится недостаточно, ядро Linux выбирает наиболее «прожорливый» процесс и убивает его, чтобы предотвратить крах всей системы. Часто жертвой становится именно postgres или rphost.
Проверим системный лог командой:
dmesg | grep -i oom
Если вы видите записи о принудительном завершении процессов, необходимо либо увеличить объем физической памяти, либо ограничить потребление ресурсов 1С и PostgreSQL через параметры Критический объем памяти процессов в консоли администрирования кластера 1С.
Проанализируем сам метод переноса данных. Формат .dt является внутренним форматом 1С и очень чувствителен к стабильности канала связи и объему оперативной памяти при распаковке. Для крупных баз (более 50-100 ГБ) профессиональное сообщество рекомендует использовать альтернативные методы:
ВыгрузкаЗагрузкаДанныхXML.epf. Этот метод медленнее, но позволяет переносить данные порциями, что значительно снижает нагрузку на память сервера.Резюмируем: Для стабильной работы связки 1С и Postgres необходимо использовать 64-битную платформу, сборку PostgreSQL, оптимизированную для 1С (например, Postgres Pro), и провести предварительную настройку лимитов памяти как в СУБД, так и в настройках кластера 1С. Регулярный мониторинг через Технологический журнал позволит своевременно выявлять утечки памяти и предотвращать падения сервисов.