← На главную

При разработке в масштабных конфигурациях (таких как 1С:ERP Управление предприятием, 1С:Комплексная автоматизация или 1С:Управление производственным предприятием) программисты нередко сталкиваются с ситуацией, когда добавление, переименование или удаление даже простого объекта метаданных — например, формы справочника или реквизита — приводит к зависанию Конфигуратора на десятки минут или даже несколько часов. Разберем основные причины такого поведения платформы 1С:Предприятие и рассмотрим пошаговые способы решения проблемы.

1. Отключение автоматического рефакторинга метаданных

Главная причина многочасового сохранения при удалении или переименовании объектов метаданных — встроенный механизм поиска ссылок и автоматического рефакторинга. При любом изменении состава метаданных Конфигуратор по умолчанию пытается просканировать абсолютно все модули, формы, макеты и общие команды огромной конфигурации, чтобы найти и обновить старые ссылки на удаляемый или изменяемый объект.

Чтобы отключить эту ресурсоемкую фоновую проверку, выполним следующие шаги в Конфигураторе:

1. Откроем главное меню Сервис и выберем пункт Параметры.
2. Перейдем на вкладку Общие.
3. Найдем группу параметров Рефакторинг при изменении... (или настройки рефакторинга для модулей и метаданных).
4. Снимем флажки, отвечающие за автоматическую проверку и поиск ссылок при переименовании и удалении объектов метаданных.
5. Нажмем кнопку Применить и сохраним настройки по кнопке ОК.

После отключения этих проверок удаление форм и реквизитов будет выполняться практически мгновенно, так как платформа не станет сканировать миллионы строк кода конфигурации ERP.

2. Экстренная остановка зависшей проверки

Если процесс обновления или сохранения уже запущен и Конфигуратор перестал отвечать, пытаясь выполнить сопоставление метаданных, не обязательно аварийно завершать процесс через диспетчер задач. Аварийное завершение 1cv8.exe может привести к повреждению кэша или блокировкам в таблицах базы данных.

Попробуем использовать стандартную комбинацию клавиш для прерывания операции:

1. Активируем окно Конфигуратора.
2. Нажмем сочетание клавиш Ctrl + Break (или Ctrl + Pause).
3. Дождемся прерывания фонового анализа метаданных. После прерывания Конфигуратор вернется к стандартной процедуре записи изменений в базу.

3. Использование расширений конфигурации для доработки форм

Проанализируем архитектурный подход к модификации типовых конфигураций. Внесение изменений непосредственно в основную конфигурацию ERP усложняет последующие обновления и увеличивает нагрузку на служебные таблицы базы данных.

Оптимальным решением для добавления новых форм или переопределения существующего интерфейса является использование расширений конфигурации:

1. Формы и элементы управления, добавленные в расширение, не меняют структуру основной конфигурации поставщика.
2. Удаление или модификация формы в расширении происходит мгновенно и не запускает глобальную реиндексацию метаданных основной конфигурации.
3. Основная конфигурация остается на полной поддержке, что ускоряет регламентные обновления типового решения.

4. Очистка служебных таблиц и локального кэша

Если сохранение конфигурации продолжает занимать длительное время даже после отключения рефакторинга, выясним причины, связанные с накоплением служебного «мусора»:

1. Фрагментация таблиц Config и ConfigSave: при регулярных сохранениях и динамических обновлениях таблицы метаданных накапливают устаревшие версии бинарных данных. Для полной пересборки структуры выгрузим информационную базу в файл .dt и загрузим ее обратно в чистую базу.
2. Очистка локального кэша Конфигуратора: закроем Конфигуратор и удалим каталоги временных файлов пользователя по путям %LOCALAPPDATA%\1C\1Cv8 и %APPDATA%\1C\1Cv8.
3. Антивирусный контроль: добавим рабочие процессы платформы (1cv8.exe, rphost.exe, ragent.exe, rmngr.exe) и временный каталог %TEMP% в исключения антивирусного мониторинга, чтобы исключить блокировку файлов при записи метаданных.

5. Оптимизация работы с СУБД MS SQL Server

При работе в клиент-серверном варианте обратим внимание на параметры базы данных на сервере СУБД:

1. Модель восстановления (Recovery Model): если база работает в режиме Full, масштабные изменения структуры метаданных вызывают лавинообразный рост журнала транзакций (.ldf). На время выполнения тяжелых обновлений целесообразно переключать модель восстановления в режим Simple.
2. Размещение временных файлов (tempdb): убедимся, что база tempdb расположена на быстрых накопителях (NVMe/SSD) и имеет достаточное количество файлов данных для параллельной обработки запросов.