При переходе на новые технологические ветки платформы 1С:Предприятие, такие как 8.3.27.2130, технические специалисты часто сталкиваются с изменением привычного поведения системы. Одной из наиболее заметных проблем становится существенное увеличение времени обновления конфигурации базы данных (нажатие кнопки F7), даже если изменения вносятся только в расширение и не затрагивают структуру метаданных основной конфигурации. В этой статье мы подробно разберем причины такого поведения платформы, проанализируем сопутствующие ошибки идентификации пользователей и определим наиболее стабильные релизы для работы.
Рассмотрим ситуацию, описанную пользователем: в конфигурации Зарплата и Управление Персоналом (ЗУП) даже минимальное изменение кода в расширении приводит к задержке обновления конфигурации БД около минуты. Для опытных разработчиков, привыкших к мгновенному применению изменений в расширениях на более старых платформах, это кажется аномалией. Однако, проанализируем технические изменения в ветке 8.3.27.
В новой версии платформы разработчики 1С существенно переработали механизмы сравнения и объединения метаданных. Теперь при каждом обновлении система проводит глубокую валидацию структуры расширения на соответствие основной конфигурации. Если в расширении присутствуют:
Платформа инициирует полный цикл проверки целостности данных. Для таких тяжелых конфигураций, как ЗУП 3.1 или ERP, объем метаданных настолько велик, что процесс сопоставления даже одного измененного модуля может занимать значительное время. Система проверяет не только синтаксис, но и логическую связность расширенных объектов с основной базой, что и создает задержку в 60 и более секунд.
Выясним причину, по которой многие специалисты опасаются ранних сборок 8.3.27. В релизе .1989 была обнаружена критическая ошибка, связанная с механизмом аутентификации. Суть проблемы заключалась в том, что при работе через веб-сервер или при использовании OpenID, платформа могла внезапно «потерять» авторизованного пользователя. Это приводило к завершению сеанса или ошибкам доступа в самый неподходящий момент — например, при выполнении фоновых заданий или записи документов.
Проанализируем, как это влияло на процесс обновления. Если в процессе фиксации изменений расширения система пыталась проверить права текущего сеанса и сталкивалась с этим багом, процесс мог зависнуть или завершиться с неочевидной системной ошибкой. К счастью, начиная с релиза 8.3.27.2214, данные проблемы официально признаны исправленными.
Разберем подробнее аппаратную составляющую процесса обновления. На платформе 8.3.27 замечено избыточное потребление оперативной памяти процессом rphost в момент реструктуризации метаданных. Это связано с тем, что новые алгоритмы проверки требуют большего объема кэшируемых данных.
Также стоит обратить внимание на работу MS SQL Server. В момент применения изменений расширений платформа активно использует временные таблицы. Посмотрим на факторы, замедляющие этот процесс:
TempDB.ЗУП могут запускаться сразу после обновления (например, расчет остатков отпусков).Для того чтобы оптимизировать работу на платформе 8.3.27, мы рекомендуем выполнить следующие действия:
1. Переход на стабильный технический релиз. На текущий момент версия 8.3.27.2214 показывает себя более стабильно, чем .2130. В ней исправлены не только ошибки авторизации, но и ряд падений кластера серверов при работе с фоновыми заданиями.
2. Управление фоновым обновлением. Проанализируем параметр «Фоновое обновление конфигурации базы данных». В некоторых сценариях в ветке 8.3.27 этот механизм может конфликтовать с активными расширениями. Попробуйте временно отключить фоновое обновление и выполнить обычное монопольное обновление (через Конфигурация -> Обновить конфигурацию базы данных). Это может парадоксально сократить общее время за счет исключения фазы слияния изменений в фоновом режиме. Для крупнообъемных баз данных при необходимости минимизировать простой также подойдет подход «Обновление через копию».
3. Проверка подписок и безопасности. Начиная с версии 8.3.27, усилен контроль за внешними компонентами. Если ваше расширение использует внешние библиотеки, убедитесь, что они корректно подписаны и имеют соответствующие права доступа. Проверка этих параметров также добавляет накладные расходы при запуске F7.
Для мониторинга состояния сеанса и платформы в процессе разработки можно использовать следующий фрагмент кода, который поможет определить версию платформы и текущего пользователя, чтобы исключить влияние бага идентификации:
// Пример проверки параметров сеанса при отладке обновления
ВерсияПлатформы = ИнфоБаза.ВерсияПлатформы();
ТекущийПользовательСистемы = ПользователиИнформационнойБазы.ТекущийПользователь();
Если Найти(ВерсияПлатформы, "8.3.27.1989") > 0 Тогда
Сообщить("Внимание: используется проблемный релиз платформы! Возможны ошибки идентификации.");
КонецЕсли;
ЗаписьЖурналаРегистрации("ОтладкаОбновления", УровеньЖурналаРегистрации.Предупреждение, , ,
"Пользователь: " + ТекущийПользовательСистемы.Имя + ", Платформа: " + ВерсияПлатформы);
Подведем итог: время обновления около минуты для ЗУП на новых релизах платформы является следствием усложнения механизмов проверки метаданных и безопасности. Если время обновления значительно превышает этот порог или сопровождается ошибками прав доступа, необходимо в первую очередь обновить платформу до релиза 8.3.27.2214 или выше. Это решит проблему с некорректным определением пользователя и повысит общую стабильность системы при работе с тяжелыми конфигурациями. Для дополнительного ускорения процедуры обновления информационных баз ЗУП можно использовать готовое решение для ускорения процесса обновления ЗУП.