Работа с расширениями в «тяжелых» конфигурациях, таких как 1С:Комплексная автоматизация 2.4 или 1С:ERP, часто сопровождается неприятным эффектом: при заимствовании любого объекта или процедуры в новое расширение Конфигуратор «зависает» на этапе «проверка корректности метаданных». Время ожидания может достигать 5–15 минут, что делает разработку крайне неэффективной. Рассмотрим причины этого поведения и разберем по шагам методы оптимизации системы.
Процесс «проверки корректности метаданных» — это сложный алгоритм валидации, при котором платформа 1С проверяет связи между объектами расширения и основной конфигурацией. В конфигурациях уровня ERP/КА количество объектов исчисляется тысячами, а связи между ними (типы данных, подсистемы, роли) образуют огромный граф. Когда вы заимствуете процедуру или форму, платформа вынуждена проанализировать не только сам объект, но и все его зависимости.
Ситуация осложняется, если используются старые версии платформы (например, 8.3.13 или 8.3.14) и устаревшие версии СУБД (SQL Server 2008), которые менее эффективно работают с системными таблицами метаданных Config и ConfigSave. Выясним, как можно сократить это время.
Одной из самых эффективных и неочевидных мер является корректировка режима совместимости расширения. Проанализируем ситуацию: по умолчанию платформа предлагает создавать расширение с режимом совместимости, соответствующим основной конфигурации (например, 8.3.12 или 8.3.14). Однако в новых режимах совместимости механизмы проверки ссылочной целостности типов стали более жесткими и ресурсоемкими.
Опытным путем установлено, что понижение режима совместимости расширения (например, до 8.3.10) при сохранении режима основной конфигурации на прежнем уровне может радикально ускорить процесс сохранения. Рассмотрим алгоритм действий:
Версия 8.3.10 (или другое более низкое значение, если это не мешает использованию нужных программных функций).Важно: Это помогает избавиться от сотен неразрешимых ссылок, которые платформа пытается валидировать в фоновом режиме, особенно если вы заимствуете сложные формы с множеством реквизитов.
Если разработка ведется в клиент-серверном варианте, Конфигуратор может конкурировать за ресурсы с другими сеансами. Для минимизации задержек на этапе записи метаданных в SQL, рекомендуется настроить максимальную изоляцию рабочего процесса для базы разработки. Разберем, как это сделать через консоль администрирования кластера 1С:
Посмотрим на параметры рабочего сервера. Для ускорения работы имеет смысл ограничить количество информационных баз на один процесс rphost. В идеале для базы разработки должен быть выделен отдельный процесс.
1.Это обеспечит монопольный доступ Конфигуратора к ресурсам конкретного процесса rphost, исключая влияние разделяемых блокировок от других баз. Стоит помнить, что данный функционал в полном объеме доступен для лицензий уровня КОРП, однако частичное управление процессами возможно и в ПРОФ-версиях через количество соединений.
Многие системные администраторы ошибочно полагают, что для ускорения 1С нужно «напихать больше оперативной памяти». Проанализируем работу Конфигуратора: этап проверки метаданных — это в основном однопоточная задача, критически зависящая от тактовой частоты процессора, а не от количества ядер.
Если ваш сервер работает на частоте 2.0–2.4 ГГц, проверка метаданных КА 2.4 неизбежно будет медленной. Для комфортной разработки требуются процессоры с частотой от 3.5 ГГц и выше. Разница между 2.5 ГГц и 3.5 ГГц на этой операции может сократить время ожидания в два и более раз. Если есть возможность, вынесите базу разработки на отдельный физический компьютер или виртуальную машину с высокочастотным CPU.
Как показывает практика коллег, в файловом режиме (особенно при размещении базы на быстром NVMe SSD) проверка метаданных проходит значительно быстрее, чем в клиент-серверном варианте на старых версиях SQL Server. Рассмотрим стратегию разработки:
.dt.При правке уже существующего в расширении кода задержек обычно нет, поэтому «тяжелую» операцию заимствования новых объектов лучше делать в файловой копии.
Поскольку метаданные хранятся в таблицах СУБД, их фрагментация напрямую влияет на скорость чтения/записи. Проанализируем состояние SQL Server. Если вы используете SQL Server 2008, убедитесь, что статистика обновлена, а индексы системных таблиц не фрагментированы.
Также крайне полезно регулярно очищать кэш конфигуратора. Удалите содержимое папок кэша в профиле пользователя:
%AppData%\1C\1cv8\
%LocalAppData%\1C\1cv8\
Иногда полезно очистить папку snacc на сервере 1С (кэш серверных вызовов), так как при интенсивной разработке расширений там скапливается большой объем временных данных, замедляющих валидацию метаданных.
Чтобы минимизировать нагрузку на систему проверки, старайтесь не заимствовать объекты целиком, если вам нужно изменить только одну процедуру. Используйте аннотации для перехвата методов:
&Вместо("РассчитатьСкидки")
Процедура Мой_РассчитатьСкидки(ДокументСсылка)
// Сначала вызываем стандартную логику, если нужно
ПродолжитьВызов(ДокументСсылка);
// Добавляем свою модификацию
Сообщить("Скидки пересчитаны моим расширением!");
КонецПроцедуры
Чем меньше «тяжелых» объектов (форм с сотнями элементов, макетов) вы затягиваете в расширение, тем быстрее будет работать проверка корректности метаданных. Удаляйте из расширения заимствованные объекты, которые вы в итоге не модифицировали.