При обновлении нетиповых конфигураций «Бухгалтерия предприятия» редакции 3.0, особенно на релизах серии 3.0.75.37 и 3.0.75.58, многие технические специалисты сталкиваются с критической ошибкой «Недостаточно памяти». Ситуация осложняется тем, что традиционные методы вроде увеличения лимита памяти через командную строку часто не приносят результата, а сам процесс сравнения и объединения на слабых компьютерах может растягиваться на долгие часы. Разберем детально причины возникновения этой проблемы и рассмотрим пошаговые методы её решения.
Для начала проанализируем ситуацию: почему именно релизы 3.0.75 стали «камнем преткновения»? В этот период компания 1С внесла масштабные изменения в метаданные конфигурации, связанные с новыми формами отчетности (например, декларация по налогу на прибыль) и внедрением электронных трудовых книжек. Объем общих модулей и количество объектов значительно возросли.
Когда мы запускаем процесс «Сравнить и объединить» для нетиповой конфигурации, Конфигуратор строит в оперативной памяти полное дерево объектов обеих конфигураций (поставщика и основной). В 32-битных версиях платформы 1С существует жесткое ограничение на адресное пространство процесса — около 2 ГБ. Как только потребление памяти при анализе метаданных приближается к порогу 1.9–2.1 ГБ, происходит аварийное завершение работы с дампом или системным сообщением об ошибке. Особенно часто это проявляется на файловых базах, где все вычислительные операции ложатся на локальную машину.
Рассмотрим самый эффективный и современный способ решения проблемы — использование 64-битной версии технологической платформы 1С:Предприятие. В отличие от 32-битной (x86), платформа x64 практически не имеет ограничений по объему используемой оперативной памяти для одного процесса, что позволяет Конфигуратору успешно завершить тяжелые операции сравнения объектов.
Выполним следующие шаги:
(x86-64).Если переход на x64 по каким-то причинам невозможен немедленно или база данных имеет внутренние повреждения структуры, проанализируем состояние таблиц информационной базы. Длительная работа в нетиповой базе и частые изменения метаданных приводят к фрагментации данных в файле 1Cv8.1CD.
Рассмотрим процедуру оптимизации:
Конфигуратор.Зачастую клиентские компьютеры («деревянные», как их называют в профессиональной среде) физически не способны обработать тяжелые релизы. В этом случае мы можем применить методику «подготовки эталонного CF-файла».
Разберем этот алгоритм по шагам:
1cv8.cf.Конфигураторе выберем пункт Конфигурация — Загрузить конфигурацию из файла... и укажем наш подготовленный .cf.Важно: При использовании метода «Загрузить конфигурацию из файла» 1С не выполняет ресурсоемкое сравнение объектов «на лету», а просто заменяет дерево метаданных целиком. Это требует в разы меньше оперативной памяти и времени. Однако помните, что этот метод затирает все локальные изменения, поэтому он подходит только если ваш .cf был подготовлен именно на базе этой конкретной копии клиента.
Иногда причиной ошибки становится некорректное состояние кэша конфигурации, который накопил «мусор» от предыдущих попыток обновления. Проанализируем ситуацию с временными файлами. 1С активно использует папку %TEMP%, и если антивирус блокирует создание тысяч мелких файлов во время объединения, Конфигуратор может выдать ошибку памяти.
Попробуем выполнить очистку вручную. Рассмотрим пример команд для создания скрипта очистки (бат-файла), который можно запустить перед обновлением:
rd /s /q "%LocalAppData%\1C\1cv8"
rd /s /q "%AppData%\1C\1cv8"
del /q /f /s "%TEMP%\*"
После удаления этих папок (при закрытых сеансах 1С) индексы метаданных будут перестроены заново, что может устранить «фантомные» ошибки нехватки ресурсов.
Если вы работаете в 32-битной среде Windows (x86), можно попытаться расширить лимит памяти для приложений с 2 ГБ до 3 ГБ. Рассмотрим использование команды bcdedit:
bcdedit /set increaseuserva 3072.Это даст Конфигуратору дополнительный гигабайт адресного пространства, которого часто как раз и не хватает для завершения процесса сравнения в релизах 3.0.75. Однако помните, что это временная мера, и полноценный переход на x64 платформу является более надежным решением.
Подводя итог, можно сказать: сочетание платформы x64 и предварительной оптимизации базы (ТиИ) полностью решает проблему «зависания» и вылетов при обновлении нетиповых конфигураций БП 3.0. Если же клиентский ПК крайне слаб, всегда используйте метод подготовки .cf на стороне разработчика.