При обслуживании и обновлении крупных, исторически нагруженных конфигураций 1С (таких как «Управление производственным предприятием» редакции 1.3) в распределенных информационных базах (РИБ) специалисты часто сталкиваются со следующей проблемой. При попытке прочитать файл обмена, содержащий одновременно и изменения данных, и обновление конфигурации, процесс аварийно завершается. На экране появляется критическая ошибка:
«Ошибка при чтении изменений при обмене РИБ: Ошибка при вызове метода контекста (ПрочитатьИзменения): Недостаточно памяти для получения результата запроса к базе данных».
Давайте подробно проанализируем, почему возникает эта ситуация, и разберем по шагам наиболее эффективные методы борьбы с ней — от простых настроек платформы до обходных административных сценариев.
Основная причина кроется в архитектуре 32-разрядных приложений Windows. По умолчанию 32-битный рабочий процесс или клиентское приложение 1С может использовать не более 2 ГБ оперативной памяти (в редких случаях при специальной настройке ОС — до 3 ГБ). Когда в периферийную базу загружается тяжелое обновление конфигурации, метод ПрочитатьИзменения() пытается загрузить в память метаданные старой и новой конфигурации, сопоставить их и подготовить таблицы базы данных к реструктуризации.
Для крупных баз объемом в сотни гигабайт и конфигураций с тысячами объектов метаданных (каковой и является УПП) этот процесс требует колоссального объема ОЗУ. Память мгновенно переполняется, и платформа аварийно завершает работу. При этом уменьшение количества объектов в транзакции при загрузке данных не помогает, так как падение происходит еще на этапе сравнения схем конфигураций, до начала обработки транзакций с данными.
Рассмотрим детально проверенные практические методы решения этой проблемы.
---
Это самый надежный и современный способ решения любых проблем с нехваткой памяти в 1С. Многие администраторы путают разрядность сервера 1С и разрядность клиента. Даже если ваш сервер 1С запущен в 64-битной версии, Конфигуратор или тонкий/толстый клиент на рабочем месте пользователя, запускающий обмен, может оставаться 32-битным (расположенным по умолчанию в папке C:\Program Files (x86)\1cv8\...).
Выполним следующие действия:
C:\Program Files\1cv8\номер_версии\bin\1cv8.exe (обратите внимание на отсутствие папки "x86" в пути).---
Если на целевом компьютере под управлением периферийной базы физически невозможно установить 64-битную платформу (например, там используется устаревшая 32-битная операционная система Windows), воспользуемся обходным путем. Мы разделим процесс обновления конфигурации и процесс получения измененных данных.
Рассмотрим по шагам этот алгоритм:
Шаг 1. Подготовка конфигурации
В главном узле базы данных зайдем в Конфигуратор и выгрузим конфигурацию в файл. Для этого выберем пункт меню Конфигурация -> Сохранить конфигурацию в файл... и сохраним файл с расширением .cf (например, update.cf). Перенесем этот файл на флешке или через файлообменник на компьютер периферийного узла.
Шаг 2. Временное «отвязывание» узла РИБ
Поскольку периферийная база находится в составе РИБ, платформа не позволит нам напрямую обновить ее конфигурацию через файл .cf. Нам нужно временно превратить базу в автономную. Для этого запустим периферийную базу в режиме «Предприятие» под правами администратора, откроем внешнюю обработку или создадим небольшую обработку со следующим кодом:
// Отключаем связь с главным узлом
ПланыОбмена.УстановитьГлавныйУзел(Неопределено);
Предупреждение("База успешно переведена в автономный режим!");
Запустим данный код. Теперь база считает себя главной и позволяет редактировать конфигурацию.
Шаг 3. Загрузка конфигурации
Закроем режим «Предприятие» и зайдем в Конфигуратор периферийной базы. Теперь нам доступна функция полной загрузки конфигурации. Выберем пункт меню Конфигурация -> Загрузить конфигурацию из файла..., укажем наш файл update.cf и запустим процесс. После завершения обязательно выполним обновление конфигурации базы данных (клавиша F7) и примем изменения.
Шаг 4. Восстановление связи с главным узлом
Снова запустим периферийную базу в режиме «Предприятие» и запустим обработку для восстановления связи. Нам нужно указать платформе, какой именно узел является для нас главным. Напишем и выполним следующий код:
// Восстанавливаем связь с главным узлом
// Вместо "ГЛ" укажите код вашего главного узла в плане обмена
ИмяПланаОбмена = "Полный"; // Укажите имя вашего плана обмена РИБ
КодГлавногоУзла = "ГЛ";
НайденныйУзел = ПланыОбмена[ИмяПланаОбмена].НайтиПоКоду(КодГлавногоУзла);
Если ЗначениеЗаполнено(НайденныйУзел) Тогда
ПланыОбмена.УстановитьГлавныйУзел(НайденныйУзел);
Предупреждение("Связь с главным узлом успешно восстановлена!");
Иначе
Предупреждение("Главный узел с указанным кодом не найден!");
КонецЕсли;
Шаг 5. Проведение обмена данными
Теперь конфигурация в периферийном узле полностью соответствует главному узлу. Запустим стандартную процедуру обмена. При чтении файла обмена платформа увидит, что конфигурации идентичны, пропустит шаг обновления метаданных и загрузит только измененные документы и справочники. Оперативная память при этом нагружаться практически не будет.
---
Если на сервере или рабочей станции установлена 32-разрядная версия Windows и процесс загрузки «падает» на отметке использования памяти около 2 ГБ, мы можем принудительно расширить этот лимит до 3 ГБ на уровне операционной системы.
Выполним следующие системные настройки:
bcdedit /set increaseuserva 3072
bcdedit /deletevalue increaseuserva
---
Иногда память забивается «мусорными» временными файлами и некорректно сопоставленными внутренними идентификаторами таблиц РИБ. Перед проведением повторного обмена выполним профилактику базы данных:
%localappdata%\1C\1Cv8 и %appdata%\1C\1Cv8.1Cv8.1CD (если база файловая) и освободит оперативную память при последующем сопоставлении схем метаданных.Применяя указанные методы, мы гарантированно обойдем ошибку нехватки памяти и сможем успешно поддерживать работоспособность и актуальность распределенной базы данных вашей компании.