Рассматриваемая нами ситуация является классическим примером долгоживущей legacy-системы. В наличии имеется связка из операционной системы Ubuntu 12 (32-бит), СУБД PostgreSQL 8.4 (32-бит) и сервера 1С:Предприятие с конфигурацией «Управление торговлей» редакции 10.3. За годы активной эксплуатации объем базы данных вырос до внушительных 30 гигабайт. При попытке переноса информационной базы на новое серверное оборудование стандартным способом — путем создания резервной копии в формате .dt — процесс аварийно завершается с ошибкой out of memory for query result.
В рамках этой статьи мы подробно разберем, почему возникает эта проблема, почему стандартный механизм выгрузки 1С оказывается неэффективным для баз большого объема, и как правильно перенести данные на новую СУБД без использования промежуточных файлов .dt.
Выясним первопричину сбоя. Несмотря на то что СУБД PostgreSQL работает стабильно, ошибка нехватки памяти возникает на стороне клиента. В контексте взаимодействия «1С — СУБД» клиентом для PostgreSQL выступает рабочий процесс сервера 1С:Предприятия под названием rphost.
Проанализируем технические аспекты этого процесса:
libpq) по умолчанию пытается полностью загрузить весь результирующий набор данных (result set) в оперативную память процесса-клиента перед тем, как передать его прикладному решению..dt платформа 1С последовательно сканирует таблицы базы данных, выполняя запросы формата SELECT * FROM.... Если в информационной базе присутствуют сверхкрупные таблицы (например, таблицы движений регистров накопления, сведений или таблицы, содержащие файлы в реквизитах типа «Хранилище значения»), библиотека пытается выгрузить гигабайты данных за один транш.rphost доступно не более 2–3 ГБ. Как только объем считываемых данных из одной большой таблицы превышает этот порог, процесс незамедлительно падает с критической ошибкой нехватки памяти.Среди квалифицированных администраторов 1С и разработчиков выгрузка в формат .dt для баз данных большого объема считается плохой практикой по следующим причинам:
.dt не является физической резервной копией базы данных. Это проприетарный логический архив, создание которого требует колоссальных вычислительных ресурсов сервера 1С для сжатия, индексации и сериализации данных «на лету»..dt на СУБД ложится колоссальная нагрузка, превосходящая стандартные процедуры создания бэкапов native-средствами самой СУБД..dt крайне неоптимален и часто прерывается из-за нехватки ресурсов или СУБД, или рабочего процесса сервера 1С.Единственным правильным и надежным решением в данном случае является использование штатных утилит резервного копирования PostgreSQL — pg_dump и pg_restore.
Важно понимать, что резервная копия (дамп), создаваемая средствами СУБД PostgreSQL, абсолютно инвариантна к разрядности платформы (32 или 64 бита) и операционной системе. Вы можете без каких-либо опасений снять дамп с 32-битной СУБД на Linux и развернуть его на 64-битной СУБД под управлением ОС Windows. Главное требование — версия PostgreSQL на целевом сервере должна быть такой же или более новой.
Рассмотрим по шагам, как выполнить этот перенос максимально эффективно. Мы будем использовать формат каталога (параметр -F d), который идеально подходит для баз объемом от 30 ГБ и выше. Данный формат позволяет выгружать данные в несколько параллельных потоков, что существенно экономит время.
Нам необязательно сохранять огромный файл бэкапа на старом сервере с ограниченным дисковым пространством. Мы можем запустить утилиту выгрузки прямо с нового 64-битного сервера Windows, обратившись к старому серверу по сети.
Выполним процедуру переноса по следующим шагам:
Шаг 1. Экспорт данных со старого сервера
Откроем командную строку (cmd или PowerShell) на новом сервере Windows и выполним команду выгрузки базы данных в режиме каталога:
"C:\Program Files\PostgreSQL\15-1C\bin\pg_dump.exe" -h 10.0.0.1 -p 5432 -U postgres -F d -j 4 -f "D:\Backup\pg_dump_ut10" ut_live
Разберем параметры этой команды подробнее:
"C:\Program Files\PostgreSQL\15-1C\bin\pg_dump.exe" — путь к утилите pg_dump на целевом сервере. Рекомендуется использовать утилиту версии, соответствующей новой СУБД.-h 10.0.0.1 — IP-адрес старого 32-битного сервера Linux.-p 5432 — порт подключения к СУБД на старом сервере.-U postgres — имя пользователя СУБД с правами суперпользователя.-F d — формат резервной копии «каталог» (directory). Данные будут сохранены в виде множества файлов таблиц внутри указанной папки.-j 4 — количество параллельных потоков для выгрузки. Позволяет значительно ускорить процесс за счет одновременного чтения нескольких таблиц.-f "D:\Backup\pg_dump_ut10" — целевой каталог на новом сервере, куда запишется дамп.ut_live — имя исходной базы данных на старом сервере.Шаг 2. Подготовка новой базы данных
На новом сервере под управлением Windows создадим пустую базу данных в PostgreSQL (например, через утилиту pgAdmin или консоль 1С) с кодировкой UTF8 и аналогичным шаблоном.
Шаг 3. Импорт данных на новый сервер
Теперь выполним восстановление данных в подготовленную пустую базу с помощью утилиты pg_restore:
"C:\Program Files\PostgreSQL\15-1C\bin\pg_restore.exe" -h localhost -p 5432 -U postgres -d ut_new -F d -j 4 "D:\Backup\pg_dump_ut10"
Проанализируем параметры восстановления:
-h localhost — восстанавливаем локально на новом сервере.-d ut_new — имя созданной пустой базы данных на новом сервере.-F d — указываем, что источник бэкапа представлен в формате каталога.-j 4 — количество потоков восстановления для ускорения процесса записи таблиц и индексов.После завершения работы утилиты останется лишь прописать новую базу данных в списке информационных баз кластера 1С:Предприятия на новом сервере.
Если по организационным причинам вам все же строго необходимо получить файл выгрузки 1С (.dt), и у вас нет возможности напрямую работать с утилитами PostgreSQL, попробуем временно оптимизировать использование оперативной памяти на старом 32-битном сервере.
Для этого выполним следующие настройки:
1. Корректировка конфигурационного файла postgresql.conf
Откроем файл настроек postgresql.conf на старом сервере Linux и скорректируем параметры выделения памяти:
shared_buffers в небольшое значение (например, 256MB или 512MB). На 32-битных системах слишком высокое значение этого буфера «съедает» адресное пространство ОС, не оставляя памяти под выполнение тяжелых внешних запросов.work_mem в значение около 32MB или 64MB. Это ограничит использование оперативной памяти для сортировки данных внутри одного запроса, заставляя СУБД сбрасывать промежуточные результаты на диск.После внесения изменений обязательно перезапустим службу PostgreSQL:
sudo service postgresql restart
2. Настройка параметров кластера 1С
Через консоль администрирования серверов 1С:Предприятия зайдем в свойства нашего рабочего сервера и настроим принудительный перезапуск рабочих процессов:
rphost автоматически перезапускался при приближении к критической отметке.Проанализировав обе методики, мы настоятельно рекомендуем отказаться от практики создания файлов .dt для баз данных объемом свыше 20 ГБ и всегда использовать прямую миграцию через штатные утилиты резервного копирования вашей СУБД.