Многие специалисты 1С сталкивались с парадоксальной ситуацией: процесс обновления базы занимает несколько часов, сервер «гудит», а в финальном окне программа радостно сообщает, что «обновление успешно завершено за 15 минут». В этой статье мы подробно разберем, почему возникает такое расхождение, какие процессы скрыты от глаз пользователя и как правильно обосновать затраченное время перед заказчиком или руководством.
Для начала проанализируем ситуацию и разделим процесс обновления на этапы. Когда мы говорим «я обновил базу», мы подразумеваем весь цикл действий, но система 1С разделяет их на технические и логические уровни. То, что видит пользователь в итоговом логе — это лишь «верхушка айсберга».
Рассмотрим основные этапы, которые проходит база данных:
Проанализируем ситуацию с точки зрения программного кода. Окно, в котором написано «Версия приложения успешно обновлена за N минут», формируется подсистемой «Обновление информационной базы» БСП. Посмотрим, что именно оно измеряет.
Важный момент: отчет БСП фиксирует только чистое время выполнения процедур-обработчиков. Рассмотрим подробнее, что входит в это время:
УстановитьПараметрыОбновления.В это время не включается время ожидания блокировок, время работы фоновых заданий, не относящихся к обновлению напрямую, и, самое главное, время, затраченное в Конфигураторе. Таким образом, если вы потратили 4 часа на техническую часть и 20 минут на выполнение кода БСП, в отчете вы увидите именно 20 минут.
В современных конфигурациях (БУХ 3.0, ERP, КА 2) используется механизм отложенных обработчиков. Рассмотрим, как это влияет на итоговые цифры. Основная идея отложенного обновления — позволить пользователям начать работу как можно быстрее, пока данные пересчитываются в фоновом режиме.
Разберем по шагам, что происходит при первом запуске:
Если в системе настроено выполнение в 8 потоков, то суммарное «процессорное время» может быть огромным, но реальное время ожидания будет меньше. Однако система фиксации времени в БСП часто суммирует время работы потоков или, наоборот, берет только интервал самого длительного. В итоге цифра в журнале обновлений становится «средней температурой по больнице».
Чтобы выяснить причину долгого обновления и зафиксировать реальные трудозатраты, нам нужно обратиться к системным инструментам 1С. Рассмотрим подробнее каждый из них.
Это самый надежный источник. Проанализируем события в журнале:
Конфигурация базы данных. Изменена. Оно фиксирует момент завершения реструктуризации.Обновление информационной базы покажут старт и финиш каждого обработчика.Пример кода (условный), как можно программно вытащить эти данные для отчета:
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ЖурналРегистрации.Дата КАК Период,
| ЖурналРегистрации.Событие КАК Событие,
| ЖурналРегистрации.Комментарий КАК Комментарий
|ИЗ
| ЖурналРегистрации КАК ЖурналРегистрации
|ГДЕ
| ЖурналРегистрации.Событие ПОДОБНО ""%Обновление%""";
// Далее анализ интервалов между первым и последним событием
Если обновление идет аномально долго (например, на этапе «сравнения»), проанализируем ТЖ. Нам интересны события DBMSSQL (или другой СУБД) и EXCP. Часто время тратится не на сам код 1С, а на ожидание ответа от дисковой подсистемы или на нехватку места в tempdb.
Если заказчик задает вопрос: «Почему в счете 5 часов, а программа пишет 10 минут?», воспользуемся следующими аргументами:
Рассмотрим ситуацию: база БП 3.0 весит 14 Гб, расширений почти нет, но обновление идет крайне долго. Посмотрим на факторы, которые «крадут» время, но не отображаются в логах:
Подведем итог нашему анализу. Время, которое пишет 1С в конце обновления — это время работы бизнес-логики БСП. Оно не является мерилом общей длительности работ.
Для корректного мониторинга мы рекомендуем:
OneScript), которые логируют каждый шаг в отдельный текстовый файл с метками времени.Помните, что «шиза» с несовпадением времени — это не баг вашей системы, а особенность архитектуры платформы 1С:Предприятие, которая разделяет техническое обслуживание и прикладную модификацию данных.