Часто системные администраторы и специалисты по 1С сталкиваются с критической ошибкой при попытке создать резервную копию информационной базы в формате .dt. Процесс обрывается сообщением: Ошибка СУБД: out of memory for query result. Проблема выглядит особенно парадоксально, если на физическом сервере достаточно свободной оперативной памяти, а мониторинг ресурсов не показывает перегрузок. Давайте вместе разберем по шагам эту ситуацию, проанализируем причины ее возникновения и рассмотрим проверенные способы решения, включая анализ технологического журнала.
Когда возникает подобная ошибка, многие администраторы начинают действовать по стандартному сценарию. Рассмотрим, что обычно предпринимается на первых этапах диагностики:
.dt.К сожалению, как показывает практика, ни один из этих шагов не устраняет ошибку out of memory, если база развернута на сервере PostgreSQL. Мониторинг показывает, что при выгрузке потребление памяти процессом не доходит даже до физического предела сервера (например, падает на отметке в 10 ГБ из доступных 16 ГБ), и происходит сбой.
Чтобы понять, как бороться с ошибкой, проанализируем архитектуру работы платформы 1С:Предприятие и концепцию построения защищенной инфраструктуры.
1. Ограничения 32-разрядной архитектуры
Самая распространенная причина кроется в использовании 32-битной версии сервера 1С:Предприятие. Архитектура 32-битных приложений (включая рабочие процессы rphost и клиентский конфигуратор) имеет жесткое ограничение на адресацию виртуальной памяти. Один 32-битный процесс физически не может использовать более 2-3 ГБ (или до ~3.8 ГБ при тонких настройках ОС) оперативной памяти.
Когда вы запускаете выгрузку базы в файл .dt, платформа 1С запрашивает у базы данных огромные массивы информации. Все эти данные платформа пытается буферизировать и сериализовать в оперативной памяти процесса перед записью в файл. Как только процесс упирается в лимит адресации в 2-3 ГБ — происходит фатальный сбой платформы, независимо от того, сколько свободной ОЗУ осталось на самом сервере.
2. «Обманчивый» текст ошибки
Формулировка «Ошибка СУБД...» пускает нас по ложному следу. На самом деле СУБД PostgreSQL в этот момент чувствует себя прекрасно и имеет достаточно ресурсов. Данная ошибка сигнализирует о том, что именно клиенту (то есть процессу 1С) не хватило оперативной памяти, чтобы принять, обработать и разместить у себя полученный от базы данных результат тяжелого запроса.
3. Внутренние лимиты PostgreSQL
В некоторых случаях ограничение может быть и на стороне самой СУБД. В стандартном PostgreSQL размер данных в одном поле типа bytea (в этом формате 1С хранит свою конфигурацию, тяжелые XML-документы и прочие бинарные данные) не может превышать 1 ГБ. Если при выгрузке таблицы размер одной строки превышает данный лимит, Postgres откажется обрабатывать такой запрос. Специализированные сборки (например, Postgres Pro) предлагают параметры вроде enable_large_allocations для обхода этого лимита.
Проанализировав причины, мы можем выбрать наиболее подходящий вариант решения проблемы в зависимости от ограничений вашей инфраструктуры.
Если специфика вашего оборудования и внешних библиотек (компонент) позволяет, самым правильным и надежным шагом будет полная переустановка сервера 1С на 64-битную версию (x64). Это полностью снимает ограничение в 2-3 ГБ на процесс rphost.
Практика показывает, что после перехода на 64-битную платформу, тяжелые базы, которые падали с ошибкой, успешно выгружаются в .dt за 30-40 минут.
Что делать, если на сервере используются специфические 32-битные драйверы оборудования или DLL-библиотеки (например, для торгового оборудования), которые не имеют 64-битных аналогов? Переводить сервер на x64 в таком случае нельзя.
Разберем хитрость клиент-серверной архитектуры. При ручной выгрузке .dt через Конфигуратор огромный объем данных буферизируется именно на стороне клиента (то есть там, где открыт Конфигуратор). Поэтому мы можем сделать следующее:
Таким образом, процесс конфигуратора, потребляющий память при формировании бэкапа, не будет ограничен рамками в 2 ГБ, и выгрузка пройдет успешно.
Рассмотрим эту ситуацию глобально. Сама фирма "1С" настоятельно не рекомендует использовать выгрузку информационной базы в формате .dt в качестве средства регулярного резервного копирования рабочих баз. Формат .dt — это технологический формат, созданный исключительно для переноса баз (например, из файлового в клиент-серверный вариант) и для работы программистов.
Для ежедневных бэкапов нужно использовать только средства самой СУБД. Это решает проблему кардинально:
.dt. Например, база размером в сотни гигабайт может восстанавливаться из дампа SQL за считанные минуты, тогда как загрузка .dt такого же объема займет несколько часов.Для PostgreSQL рекомендуется настроить автоматическое создание бэкапов с использованием штатной утилиты pg_dump или настроить непрерывное архивирование журналов транзакций (WAL).
Пытаясь решить ошибку нехватки памяти, многие администраторы начинают бесконтрольно изменять файл postgresql.conf. Особое внимание уделим параметру work_mem. В отличие от shared_buffers, который выделяется один раз на весь сервер БД, память по параметру work_mem выделяется операционной системой на каждую операцию сортировки или хеширования для каждого отдельного запроса.
Если вы завысите work_mem (например, выставите несколько гигабайт), сложные запросы от платформы 1С спровоцируют лавинообразное потребление памяти всем сервером СУБД. Это приведет к тому, что в Linux сработает системный механизм OOM Killer (Out of Memory Killer), который принудительно «убьет» процесс СУБД для спасения операционной системы. Поэтому подходить к тюнингу PostgreSQL нужно крайне осторожно.
Мы подробно проанализировали причину сбоя при формировании дампа базы. Ошибка out of memory for query result — это верный сигнал к тому, что ваш процесс 1С задыхается в рамках 32-битной архитектуры.
Используйте 64-разрядные клиенты и серверы 1С везде, где это технически возможно. А для обеспечения надежности данных навсегда откажитесь от ночных выгрузок в .dt, перенастроив систему на использование профессиональных средств резервного копирования на уровне СУБД.