Восстановление базы данных 1С из DT-файла в серверный режим, особенно когда речь идет о значительных объемах данных (как, например, 35 ГБ в рассматриваемом случае), может быть сопряжено с рядом сложностей. Пользователи часто сталкиваются с ошибками вида "Передача данных прервана по инициативе принимающей стороны" или "An existing connection was forcibly closed by the remote host", а также с проблемами прав доступа, такими как "could not rename temporary statistics file... Permission denied". В этой статье мы подробно разберем, как диагностировать и решить эти проблемы на примере связки 1С:Предприятия с PostgreSQL на операционной системе Windows.
Прежде чем погружаться в сложные настройки и устранение специфических ошибок, мы убедимся, что базовые шаги по подготовке DT-файла и серверного окружения были выполнены корректно. Эти шаги помогут исключить наиболее очевидные причины сбоев и сосредоточиться на более глубоких проблемах.
Проверим целостность DT-файла: Самый первый и важный шаг — это удостовериться, что ваш DT-файл не поврежден и содержит корректные данные. Для этого попробуем загрузить ваш DT-файл в файловую базу данных 1С. Если загрузка проходит успешно и без ошибок, это является хорошим индикатором того, что сам DT-файл, скорее всего, корректен, и проблема кроется в серверном окружении, настройках 1С:Предприятия или СУБД PostgreSQL.
Проведем тестирование и исправление информационной базы: Крайне рекомендуется перед выгрузкой в DT-файл (или из файловой базы, если она была развернута из проблемного DT-файла) выполнять операцию "Тестирование и исправление информационной базы" через конфигуратор. Эта процедура помогает выявить и устранить логические ошибки в данных, которые могут помешать успешной загрузке или некорректно себя проявлять в серверной базе. Для выполнения этой операции:
Кроме того, может быть полезно провести реструктуризацию информационной базы через конфигуратор. Иногда это помогает обновить внутреннюю структуру таблиц и устранить потенциальные проблемы, связанные с изменениями в конфигурации или данными.
Убедимся в лицензионности 1С:Предприятия: Хотя это редко является прямой причиной ошибки загрузки DT-файла, в некоторых случаях проблемы с нелицензионным программным обеспечением могут проявляться непредсказуемо и приводить к неожиданному поведению. Мы проверим и убедимся, что ваш сервер 1С:Предприятия имеет действующую и корректно установленную лицензию.
Помним о назначении DT-файлов: Важно понимать, что формат DT (Data Transfer) предназначен в первую очередь для миграции между файловым и клиент-серверным режимами работы, а также для переноса баз данных. Он не является оптимальным или рекомендованным форматом для регулярного резервного копирования. Для серверных баз данных 1С мы настоятельно рекомендуем использовать нативные средства СУБД, такие как утилита pg_dump для PostgreSQL, или штатные механизмы резервного копирования 1С:Предприятия, если они поддерживаются для вашей СУБД. Использование DT-файлов для бэкапов не гарантирует успешного восстановления.
Ошибка "Передача данных прервана по инициативе принимающей стороны" или её англоязычный аналог "An existing connection was forcibly closed by the remote host" часто указывает на разрыв соединения между сервером 1С (процессом rphost) и сервером СУБД (PostgreSQL). Чтобы выяснить истинную причину этого разрыва, нам потребуется анализировать логи и системные ресурсы.
Проанализируем логи PostgreSQL: Это ваш основной и наиболее информативный источник для диагностики проблем на стороне СУБД. Мы внимательно изучим сообщения, предшествующие моменту разрыва соединения. Типичное сообщение, указывающее на принудительное закрытие соединения клиентом или со стороны сервера СУБД, выглядит так:
LOG: could not receive data from client: An existing connection was forcibly closed by the remote host.
Иногда в логах могут встречаться другие сообщения, например, LOG: received fast shutdown request. Если мы видим подобные сообщения, это может указывать на наличие запланированных задач, которые останавливают PostgreSQL, или на нехватку системных ресурсов, которая приводит к аварийному или принудительному завершению работы СУБД. Мы внимательно проверим планировщик задач Windows на наличие автоматических перезапусков или остановок службы PostgreSQL, а также журнал событий Windows на предмет критических ошибок.
Оценим доступные ресурсы сервера: Процесс длительной загрузки больших баз данных потребляет значительное количество оперативной памяти, процессорного времени и дисковых операций ввода/вывода. Мы должны убедиться, что сервер не испытывает дефицита ресурсов:
rphost) и PostgreSQL активно используют оперативную память для кэширования данных и выполнения запросов. Для базы данных в 35 ГБ на сервере с 16 ГБ RAM настройки по умолчанию могут быть недостаточными. Нехватка памяти может привести к принудительному закрытию соединений, аварийному завершению процессов или сбросу данных на диск, что резко замедляет работу.Мы используем встроенные средства мониторинга Windows (Диспетчер задач, Монитор ресурсов) для отслеживания загрузки CPU, RAM и дисков во время попытки загрузки DT-файла. Мы обращаем особое внимание на использование памяти процессами rphost и postgres.exe.
Проверим сетевые аспекты: Несмотря на то, что загрузка базы данных выполняется локально на сервере, сетевой стек Windows все равно задействован. Проблемы с сетевыми драйверами, брандмауэром Windows, сетевыми адаптерами или другим сетевым программным обеспечением (например, VPN-клиентами) могут вызывать принудительное закрытие соединений. Мы проанализируем системный журнал Windows на наличие ошибок, связанных с сетью, и временно отключим брандмауэр Windows для проверки, если это возможно в контролируемой среде.
Учтем тайм-ауты: Как в PostgreSQL (например, параметры statement_timeout, idle_in_transaction_session_timeout), так и на стороне сервера 1С:Предприятия могут быть установлены различные тайм-ауты для соединений и выполнения запросов. Если операция загрузки данных занимает слишком много времени и превышает установленный тайм-аут, соединение может быть разорвано. Хотя настройки по умолчанию обычно достаточно либеральны, в некоторых случаях их стоит проверить и при необходимости увеличить.
Одна из ключевых проблем, которая часто возникает при работе PostgreSQL на Windows с большими объемами данных и интенсивными операциями (такими как загрузка DT-файла), проявляется сообщением в логах:
LOG could not rename temporary statistics file "pg_stat_tmp/global.tmp" to "pg_stat_tmp/global.stat": Permission denied
Эта ошибка особенно характерна для Windows из-за фундаментальных особенностей работы с блокировками файлов в этой операционной системе, которые значительно отличаются от Linux. В Windows файл может быть заблокирован для эксклюзивного использования другим процессом, даже если это сам PostgreSQL, пытающийся получить доступ к своим же временным файлам статистики, если они были временно заблокированы другой службой или даже другим потоком PostgreSQL в другом контексте.
Мы выясним, как решить эту проблему, переместив каталог временных файлов статистики PostgreSQL на другой физический диск или в другое место с менее строгим контролем доступа, где нет конфликтов с другими системными процессами или антивирусным ПО.
Остановим службу PostgreSQL: Прежде чем вносить какие-либо изменения в конфигурацию PostgreSQL или перемещать файлы, мы обязательно остановим службу PostgreSQL. Это гарантирует, что все файлы разблокированы и мы можем безопасно манипулировать ими.
Переместим каталог pg_stat_tmp:
C:\Program Files\PostgreSQL\9.6\data) найдем подкаталог pg_stat_tmp.D:\Postgres_Stats).pg_stat_tmp в этот новый каталог. Важно переместить именно содержимое, а не сам каталог, чтобы сохранить его структуру.Настроим postgresql.conf: Откроем файл postgresql.conf, который обычно находится в каталоге данных PostgreSQL (или в data подкаталоге), используя текстовый редактор с правами администратора. В этом файле мы добавим или изменим параметр stats_temp_directory, указав полный путь к новому каталогу:
# Custom settings for pg_stat_tmp location
stats_temp_directory = 'D:/Postgres_Stats' # Укажите ваш новый путь
Мы обратим внимание, что путь в файле конфигурации PostgreSQL указывается с прямыми слэшами (/), даже если вы работаете в операционной системе Windows. Если этот параметр уже существует в файле и закомментирован (то есть, начинается с символа #), мы раскомментируем его (уберем #) и изменим значение на наш новый путь.
Проверим права доступа: Мы убедимся, что у учетной записи пользователя, под которой запускается служба PostgreSQL (обычно это специальная учетная запись Network Service или локальная системная учетная запись), есть полные права на чтение, запись и изменение для нового каталога (например, D:\Postgres_Stats). Недостаточные права доступа могут снова привести к ошибкам.
Запустим службу PostgreSQL: После внесения всех необходимых изменений в конфигурационный файл и сохранения его, а также после проверки прав доступа, мы запустим службу PostgreSQL.
Повторим попытку загрузки DT-файла: После выполнения всех этих шагов мы повторим попытку загрузки DT-файла в серверную базу 1С. В случае, описанном в исходной теме, это решило проблему, хотя и заняло значительно больше времени (8 часов для 35 ГБ базы данных, которая затем "раздулась" до 65 ГБ).
Для улучшения производительности и стабильности работы 1С:Предприятия с PostgreSQL, особенно при работе с большими базами данных и интенсивными операциями, крайне важно правильно настроить параметры СУБД. Настройки PostgreSQL по умолчанию часто неоптимальны для продакшн-серверов, работающих под высокой нагрузкой.
Мы откроем файл postgresql.conf, расположенный в каталоге данных PostgreSQL, используя текстовый редактор с правами администратора, и внесем следующие изменения. Мы не забудем раскомментировать (убрать символ #) нужные строки, чтобы изменения вступили в силу:
shared_buffers: Этот параметр определяет объем памяти, который PostgreSQL выделяет для кэширования наиболее часто используемых данных. На Windows мы рекомендуем устанавливать его не выше 25% от доступной оперативной памяти (RAM), чтобы оставить достаточно памяти для операционной системы и процессов 1С (таких как rphost). Например, для сервера с 16 ГБ RAM это может быть 3-4 ГБ.
shared_buffers = 4GB # Например, для 16GB RAM
work_mem: Этот параметр определяет объем памяти, который используется для операций сортировки и хеширования в рамках одного запроса. Если во время выполнения запросов требуется много памяти для этих операций, а значение work_mem слишком низкое, PostgreSQL будет сбрасывать временные данные на диск, что резко замедляет работу. Мы рекомендуем увеличить его до 64 МБ, 128 МБ или даже выше, в зависимости от количества одновременных пользователей и сложности выполняемых запросов.
work_mem = 128MB # Рекомендуемое значение для рабочих серверов
effective_cache_size: Этот параметр является оценкой объема памяти, доступного для кэширования данных на уровне операционной системы. PostgreSQL использует это значение для оптимизатора запросов, чтобы более точно предсказать, сколько данных может быть закэшировано операционной системой. Мы рекомендуем установить его на 50-75% от общей оперативной памяти.
effective_cache_size = 10GB # Например, для 16GB RAM
maintenance_work_mem: Этот параметр используется для операций обслуживания базы данных, таких как VACUUM, CREATE INDEX, ALTER TABLE ADD FOREIGN KEY. Во время загрузки данных или создания индексов, более высокое значение maintenance_work_mem может значительно ускорить эти процессы. Мы рекомендуем установить его выше work_mem, например, 256 МБ или 512 МБ.
maintenance_work_mem = 512MB # Рекомендуемое значение для обслуживания
Настройки для SSD: Если ваша база данных расположена на SSD-диске, мы должны оптимизировать следующие параметры, поскольку SSD-накопители имеют существенно иные характеристики производительности по сравнению с традиционными HDD:
random_page_cost: Установим более низкое значение (например, 1.1 или 1.0 вместо значения по умолчанию 4.0), так как случайный доступ к данным на SSD значительно быстрее, чем на HDD. Это поможет оптимизатору запросов принимать более эффективные решения.checkpoint_timeout и max_wal_size: Мы также можем рассмотреть увеличение этих параметров для снижения износа SSD и оптимизации работы с WAL-журналами (Write-Ahead Log) во время интенсивных операций записи. Например, мы можем установить checkpoint_timeout = 10min и max_wal_size = 4GB.
random_page_cost = 1.1
checkpoint_timeout = 10min
max_wal_size = 4GB
После изменения любых параметров в файле postgresql.conf крайне важно перезапустить службу PostgreSQL для применения новых настроек. Изменения не вступят в силу до перезапуска.
В рассматриваемом случае база данных после загрузки из DT-файла "раздулась" с 35 ГБ до 65 ГБ. Это довольно распространенное явление при интенсивных операциях записи, и мы выясним его причины:
Фрагментация: При загрузке большого объема данных, особенно если это происходит неоптимально или без достаточного свободного пространства, база данных может сильно фрагментироваться, что приводит к увеличению ее физического размера на диске.
Индексы: После загрузки большого объема данных PostgreSQL может автоматически перестроить или создать индексы для обеспечения быстрого поиска. Индексы сами по себе занимают значительное место, и их перестроение во время или сразу после загрузки данных может заметно увеличить общий размер базы. Это особенно заметно, если в базе много индексов или они сложной структуры.
WAL-журналы (Write-Ahead Log): Во время интенсивных операций записи, таких как загрузка большого DT-файла, PostgreSQL активно использует WAL-журналы для обеспечения целостности данных. Хотя WAL-журналы не являются частью самой базы данных, они могут временно занимать значительный объем дискового пространства. Их размер и правила очистки регулируются параметрами max_wal_size и min_wal_size в postgresql.conf.
"Мертвые" кортежи: PostgreSQL использует модель многоверсионности (MVCC). После больших операций записи, обновлений или удалений в базе данных может остаться много "мертвых" кортежей (старых версий строк), которые занимают место, но уже не используются. Эти "мертвые" кортежи не освобождают место на диске автоматически. Запуск команды VACUUM (или VACUUM FULL, которая является более агрессивной и освобождает больше места, но блокирует таблицу) помогает очистить это пространство и уменьшить физический размер базы данных.
Для борьбы с "раздуванием" и освобождения дискового пространства мы рекомендуем регулярно выполнять команду VACUUM ANALYZE или настраивать автоматический запуск автовакуума (autovacuum) в PostgreSQL. В случае сильного "раздувания" после загрузки мы можем вручную выполнить:
VACUUM VERBOSE ANALYZE;
-- или для более радикального сжатия, которое блокирует таблицы на время выполнения:
VACUUM FULL VERBOSE ANALYZE;
Мы должны быть осторожны с VACUUM FULL, так как она блокирует таблицы и может быть неприемлема для активно используемых баз данных в рабочее время.
После успешной загрузки DT-файла и устранения основных проблем, мы рассмотрим дополнительные шаги для повышения стабильности, производительности и надежности вашей системы 1С + PostgreSQL:
Обновим PostgreSQL: Версия PostgreSQL 9.6.7, упомянутая в проблеме, достаточно устарела. Мы настоятельно рекомендуем рассмотреть возможность обновления до более новой стабильной версии PostgreSQL (например, 13 или 14), которая включает значительные улучшения в производительности, стабильности и безопасности, особенно для работы на Windows и с SSD-накопителями. Перед обновлением мы всегда проверяем матрицу совместимости версий 1С:Предприятия и PostgreSQL, чтобы избежать несовместимостей.
Используем pg_dump для бэкапов: Для создания надежных и консистентных резервных копий серверных баз данных мы настоятельно рекомендуем использовать утилиту pg_dump, которая поставляется вместе с PostgreSQL. Это наиболее надежный и поддерживаемый способ бэкапирования и восстановления серверных баз данных, который обеспечивает целостность данных и совместимость с различными версиями PostgreSQL. Мы также можем рассмотреть использование инкрементальных бэкапов с помощью pg_basebackup для очень больших баз.
Рассмотрим переход на Linux: Как уже упоминалось в обсуждении, многие проблемы с производительностью и правами доступа PostgreSQL на Windows, особенно при больших нагрузках и интенсивных операциях ввода/вывода, значительно проще решаются в среде Linux. Это связано с особенностями работы операционной системы Linux с файловой системой, памятью и процессами, которые лучше подходят для высоконагруженных СУБД. Если такая возможность есть, мы рассмотрим миграцию на Linux для повышения стабильности и производительности.
Мониторинг сервера: Мы рекомендуем наладить постоянный мониторинг ресурсов сервера (CPU, RAM, дисковые операции ввода/вывода, сетевая активность) и логов PostgreSQL. Это позволит оперативно выявлять и устранять потенциальные проблемы, а также получать представление о производительности системы в реальном времени. Инструменты мониторинга могут включать Zabbix, Prometheus с Grafana или специализированные решения для PostgreSQL.
Следуя этим рекомендациям и шагам, вы сможете не только успешно загрузить большой DT-файл в серверную базу 1С на PostgreSQL, но и значительно улучшить стабильность и общую производительность вашей информационной системы 1С.