Загрузка файлов резервных копий формата .dt объемом более 2-3 гигабайт часто превращается в серьезную проблему для администраторов систем 1С:Предприятие. Процесс импорта прерывается бессистемными ошибками вроде «Соединение разорвано администратором», а в логах СУБД PostgreSQL регистрируются критические события unexpected EOF on client connection with an open transaction и FATAL: terminating connection because protocol sync was lost.
В этой статье мы подробно разберем, почему возникает данная проблема, что происходит на стыке взаимодействия сервера приложений 1С и СУБД PostgreSQL в момент распаковки данных, и как настроить систему для гарантированного импорта базы любого объема.
---
Для начала проанализируем поведение системы в момент выполнения операции «Загрузить информационную базу». Файл .dt представляет собой сильно сжатый ZIP-архив, содержащий сериализованные данные таблиц и конфигурацию. Когда мы запускаем импорт через Конфигуратор, происходят следующие процессы:
rphost) начинает читать файл архива и декомпрессировать его.TEMP операционной системы для промежуточного хранения бинарных данных.rphost открывает транзакцию в СУБД PostgreSQL и начинает массовую заливку данных при помощи высокопроизводительной команды COPY FROM STDIN BINARY.Исходя из логов технологического журнала 1С и системных событий, обрыв загрузки происходит по двум основным сценариям:
Сценарий 1. Исчерпание дискового пространства во временной папке. Служба сервера 1С работает под системной учетной записью (по умолчанию USR1CV8). Временные файлы при распаковке создаются в профиле этого пользователя на системном диске C:\. Если исходный архив весит 2.7 ГБ, то в распакованном виде база в СУБД может занимать 60 ГБ. При этом в процессе распаковки на диске C:\ может потребоваться в 2 или 3 раза больше свободного места от конечного объема базы (до 120–180 ГБ). Как только место на диске физически заканчивается, процесс rphost падает без внятного предупреждения, обрывая соединение с PostgreSQL.
Сценарий 2. Зависание rphost и реакция менеджера кластера rmngr. Когда рабочий процесс rphost уходит в тяжелую однопоточную операцию декомпрессии и отправки данных, он перестает отвечать на внутренние запросы проверки доступности («пинги»), которые шлет ему менеджер кластера rmngr. Менеджер кластера, не получив ответа в течение установленного таймаута, считает процесс rphost зависшим и принудительно «убивает» его. СУБД мгновенно фиксирует обрыв сокета со стороны клиента (unexpected EOF on client connection).
---
Рассмотрим последовательность действий, которая поможет настроить серверную инфраструктуру для бесперебойной загрузки базы данных.
Поскольку системный диск C:\ часто имеет ограниченный объем, необходимо перенести директорию временных файлов службы 1С на другой, более емкий и производительный накопитель (желательно SSD/NVMe).
Для этого выполним следующие действия:
services.msc.D:\) новую папку для временных файлов, например: D:\1C_TEMP.USR1CV8 или Локальная система).TEMP и TMP для учетной записи службы 1С.Альтернативный и более надежный способ перенаправить временные файлы конкретно для сервера 1С — отредактировать параметры запуска службы в реестре Windows:
regedit.HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\1C:Enterprise 8.3 Server Agent...ImagePath и добавим в конец строки запуска ключ, указывающий на новую временную папку (если применимо для вашей версии платформы), либо зададим переменную окружения непосредственно перед запуском процесса через конфигурационные файлы ОС.Наиболее простым решением является глобальное изменение переменных TEMP и TMP в свойствах среды для пользователя USR1CV8 через панель управления учетными записями.
---
Чтобы менеджер кластера rmngr не убивал рабочий процесс rphost во время выполнения длительных дисковых операций, увеличим лимиты ожидания ответа процессов.
Начиная с версии платформы 1С:Предприятие 8.3.13, разработчики добавили параметры регулирования пинга рабочих процессов. Мы можем настроить их при запуске службы агента ragent с помощью ключей командной строки:
--pingPeriod — интервал опроса процессов кластера (в миллисекундах).--pingTimeout — время ожидания ответа на опрос (в миллисекундах).Рекомендуется временно увеличить значение --pingTimeout до 20000–30000 мс (по умолчанию значение составляет около 5000 мс). Это позволит процессу rphost легитимно «молчать» во время пиковых нагрузок декомпрессии без риска аварийного завершения менеджером кластера.
---
Дефолтная конфигурация СУБД PostgreSQL не адаптирована под единовременный залив гигабайтных массивов данных. Перед началом загрузки .dt целесообразно скорректировать параметры в конфигурационном файле postgresql.conf. После успешного импорта эти настройки можно будет вернуть к рабочим значениям.
Откроем postgresql.conf и отредактируем следующие параметры:
# Увеличиваем объем памяти для обслуживания (создание индексов, транзакции COPY)
maintenance_work_mem = 4GB
# Увеличиваем лимит блокировок, так как 1С создает тысячи таблиц одновременно
max_locks_per_transaction = 256
# Временно увеличиваем размер лога предзаписи, чтобы избежать частых чекпоинтов
max_wal_size = 16GB
checkpoint_timeout = 30min
# Отключаем синхронную запись на диск для ускорения импорта (критично для HDD)
synchronous_commit = off
fsync = off
Важно: После успешного развертывания базы обязательно верните параметры fsync в значение on и выполните перезапуск службы PostgreSQL, иначе в случае сбоя питания СУБД данные могут быть повреждены.
---
Поскольку СУБД PostgreSQL и сервер приложений 1С работают на одной физической машине под управлением Windows Server, обмен данными происходит через локальную петлю обратной связи (Loopback, IP-адрес 127.0.0.1). При передаче колоссального объема данных сетевой стек Windows может блокировать сокеты.
Отключим встроенные механизмы оптимизации сетевого трафика, которые на локальных Loopback-соединениях могут вызывать непредвиденные разрывы сессий.
Запустим командную строку (cmd) от имени Администратора и выполним следующие команды:
netsh int tcp set global chimney=disabled
netsh int tcp set global rss=disabled
netsh int tcp set global netdma=disabled
Это предотвратит разгрузку сетевого протокола силами сетевой карты, исключит аппаратные сбои виртуального сетевого адаптера и стабилизирует передачу бинарных пакетов между 1С и PostgreSQL.
---
На современных версиях платформы 1С:Предприятие импорт данных из формата .dt по умолчанию выполняется в многопоточном режиме для ускорения процесса. Однако при работе с PostgreSQL это может приводить к взаимным блокировкам и перегрузке дискового накопителя.
Рекомендуем выполнять загрузку большой базы через командную строку конфигуратора, принудительно ограничив количество потоков до одного с помощью ключа -JobsCount 1:
"C:\Program Files\1cv8\8.3.XX.XXXX\bin\1cv8.exe" DESIGNER /S "ИмяСервера\ИмяБазы" /RestoreIB "C:\Backup\base.dt" /N "Администратор" /P "Пароль" -JobsCount 1
Такой подход снизит пиковую утилизацию диска и процессора, минимизирует вероятность таймаутов процессов СУБД и 1С.
---
Мы подробно разобрали причины падения сервера 1С при загрузке тяжелых архивов. Основное внимание следует уделять объему свободного места на диске с папкой TEMP и внутренним таймаутам кластера 1С.
Однако стоит помнить, что формат .dt является внутренним логическим средством выгрузки 1С:Предприятия. Он предназначен для переноса конфигурации и данных между различными СУБД (например, при переходе с MS SQL на PostgreSQL), но не должен использоваться в качестве регулярного инструмента резервного копирования больших баз данных.
Для регулярного резервного копирования и быстрого восстановления баз данных объемом свыше 50 ГБ всегда используйте штатные средства СУБД PostgreSQL — утилиты pg_dump и pg_restore. Они работают напрямую с физической структурой данных, выполняют импорт в десятки раз быстрее и не зависят от стабильности и таймаутов рабочих процессов сервера 1С.