Работа с крупными базами данных в распределенных информационных системах (РИБ) на платформе 1С всегда сопряжена с повышенной нагрузкой на аппаратные ресурсы. Одной из наиболее сложных конфигураций в этом плане является 1С:Управление производственным предприятием (УПП). Из-за ее огромного объема метаданных стандартные механизмы обновления РИБ часто дают сбой, вызывая критические ошибки нехватки памяти или рассинхронизации узлов.
В этой статье мы подробно разберем, как справиться с двумя взаимосвязанными проблемами: блокировкой обмена из-за некорректно зарегистрированных изменений конфигурации и падением рабочих процессов СУБД PostgreSQL и сервера 1С с ошибкой «Недостаточно памяти для получения результата запроса к базе данных».
---
Данная ошибка возникает в центральной базе (ЦБ) при попытке загрузить файл обмена от периферийного узла (ПБ). Это классическое следствие ручного «обходного» обновления, когда файл конфигурации .cf загружается непосредственно в периферийную базу с временным отключением от главного узла.
Почему это происходит: когда вы обновляете конфигурацию в центральной базе, платформа автоматически регистрирует изменения структуры метаданных для отправки во все периферийные узлы. Если вы обновили периферийную базу вручную, ЦБ «не знает» об этом. В ее плане обмена продолжает висеть признак того, что подчиненный узел должен сначала принять конфигурационные изменения из файла обмена. До тех пор, пока этот признак активен, ЦБ будет блокировать любые пакеты данных с этого узла во избежание повреждения структуры данных.
Рассмотрим несколько эффективных способов решения этой проблемы.
Самый простой и безопасный способ — воспользоваться специализированной обработкой, встроенной во многие типовые конфигурации (включая УПП).
После этого признак необходимости обновления конфигурации для узла будет снят, и центральная база успешно примет файл обмена.
Если база данных имеет внушительный размер и стандартные обработки зависают, мы можем очистить регистрацию изменений напрямую через СУБД. В PostgreSQL за регистрацию изменений конфигурации отвечает системная таблица с суффиксом _ConfigChngRec.
Выполним следующие шаги:
TRUNCATE TABLE _ConfigChngRec;
Если требуется удалить регистрацию только для конкретного периферийного узла, необходимо предварительно определить его внутренний идентификатор в таблице планов обмена и выполнить выборочное удаление:
DELETE FROM _ConfigChngRec WHERE NodeRef = 'Идентификатор_Узла';
Этот метод работает мгновенно и полностью решает проблему блокировки обмена без необходимости монопольного доступа к базе.
Мы можем написать небольшую одноразовую обработку или выполнить код в консоли кода, чтобы программно очистить регистрацию изменений:
УзелОбмена = ПланыОбмена.НайтиПоКоду("КодВашегоУзла");
Если Не УзелОбмена.Пустая() Тогда
ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена, Метаданные.СвойстваОбъектов);
// Или полный сброс изменений для узла:
// ПланыОбмена.УдалитьРегистрациюИзменений(УзелОбмена);
КонецЕсли;
---
Эта проблема носит чисто технический характер и связана с ограничениями выделения оперативной памяти процессам СУБД и сервера 1С. Ситуация усугубляется, если сервер имеет всего 16 ГБ ОЗУ, на котором одновременно крутится Windows Server и виртуальная машина Ubuntu с PostgreSQL (выделено 8 ГБ).
Выясним причины и разберем системные шаги для обхода этой ошибки.
Если на сервере установлена 32-битная версия службы сервера 1С (rphost), то один рабочий процесс физически не может адресовать более 2 ГБ (в редких случаях 3 ГБ) оперативной памяти. При формировании тяжелых файлов обмена РИБ (сериализации сотен тысяч объектов в XML) этот лимит исчерпывается за несколько минут.
Решение: Установите 64-разрядный сервер 1С и используйте 64-разрядный клиент. Это снимет ограничение адресного пространства процесса rphost, позволяя ему утилизировать всю доступную память системы.
При наличии всего 16 ГБ физической памяти на сервере, разделение ресурсов 50/50 (8 ГБ под Windows + сервер 1С и 8 ГБ под виртуальную машину с СУБД) является критическим фактором. Во время реструктуризации тяжелых таблиц УПП операционная система Windows уходит в жесткий своп (swap), что приводит к критическому замедлению и сбоям выделения памяти.
Решение: На время проведения обновления и первой синхронизации временно урежьте оперативную память виртуальной машины Ubuntu с PostgreSQL до 4 ГБ. Это освободит дополнительно 4 ГБ физического ОЗУ для операционной системы Windows и рабочих процессов сервера 1С, предотвратив аварийное завершение работы служб.
Для стабильной работы СУБД под нагрузкой при ограниченных ресурсах (например, при выделении 8 ГБ под Ubuntu) стандартные параметры PostgreSQL необходимо оптимизировать. Изменим следующие параметры в файле postgresql.conf:
shared_buffers — установим на уровне 2 ГБ (оптимально 25% от всей памяти виртуальной машины).work_mem — установим в диапазоне от 32MB до 64MB. Слишком высокое значение при большом количестве параллельных соединений заставит ОС Linux активировать механизм OOM Killer и аварийно завершить процессы СУБД.maintenance_work_mem — временно поднимем до 1 ГБ на период обновления структуры базы данных. Это ускорит создание индексов и реструктуризацию таблиц.Начиная с платформы 8.3, в свойствах рабочего сервера 1С можно гибко настраивать параметры расхода памяти рабочими процессами:
0 (без ограничений) либо зададим лимит в 90% от доступной Windows памяти, чтобы процессы не перезапускались аварийно в процессе формирования пакета обмена.По умолчанию платформа пытается выгрузить все зарегистрированные изменения в рамках одной транзакции и одного файла, что приводит к переполнению буфера памяти. Мы можем настроить разбиение транзакций.
Если обмен выполняется программно или через настраиваемые правила обмена, установим параметр ЭлементовВТранзакции (например, равным 1000 или 2000). Это позволит платформе записывать данные порциями, своевременно сбрасывая кэш памяти на диск.
В условиях жесткого дефицита ресурсов перед выполнением тяжелого обмена обязательно выполните превентивные меры:
Database Server / ragent).sudo systemctl restart postgresql).Перезапуск служб освободит заблокированную фрагментированную память, давая процессу 1С максимальный «запас прочности» для успешной выгрузки пакета данных.