Переход между релизами 1С:ERP 2.5.17 и 2.5.22 является одним из наиболее трудоемких этапов сопровождения системы за последнее время. Это связано не просто с изменением метаданных, а с глобальной миграцией данных в рамках внедрения «Новой архитектуры взаиморасчетов». В процессе обновления запускается более 300 отложенных обработчиков, которые могут «зависать» или работать крайне медленно. Проанализируем причины этого поведения и разберем по шагам, как обеспечить стабильное завершение обновления.
Рассмотрим, что именно происходит «под капотом» системы. В версии 2.5.22 разработчики окончательно перевели механизмы распределения затрат и расчета себестоимости на новую логику. Основная нагрузка ложится на регистры накопления, такие как РасчетыСПоставщиками, РасчетыСКлиентами и ВыручкаИСебестоимостьПродаж. Проблема заключается в том, что система меняет логику хранения ключей аналитики. Это требует полной перезаписи миллионов записей в таблицах базы данных.
Выясним причину, по которой первые 200 обработчиков пролетают быстро, а остальные тормозят. Как правило, первые задания обрабатывают небольшие справочники или сервисные настройки. Тяжелые задания, работающие с регистрами накопления, обычно стоят в конце очереди. Когда дело доходит до них, объем транзакций возрастает экспоненциально.
Одной из наиболее частых причин «замирания» процесса является неоптимальная настройка MS SQL Server. Посмотрим на параметр MAXDOP (Maximum Degree of Parallelism). Если этот параметр установлен в значение 0 (использовать все доступные ядра), SQL Server может пытаться распараллелить выполнение даже простых запросов внутри циклов обновления. Это создает огромные накладные расходы на координацию потоков и приводит к взаимным блокировкам.
Рекомендуемые действия по настройке SQL:
MAXDOP равным 1 на время выполнения тяжелых обработчиков. Это заставит SQL выполнять каждую операцию в одном потоке, что зачастую работает быстрее за счет отсутствия ожиданий на синхронизацию.Cost Threshold for Parallelism. Если он оставлен в значении по умолчанию (5), поднимите его до 50. Это предотвратит попытки сервера распараллеливать «дешевые» запросы.Многие забывают, что при выполнении обработчиков обновления объекты (справочники, документы) физически перезаписываются. Если в системе установлены расширения, содержащие подписки на события ПередЗаписью или ПриЗаписи, они будут вызываться для каждого объекта. Даже «пустое» расширение создает дополнительный контекст выполнения, который замедляет процесс в десятки раз.
Также проанализируем ситуацию с версионированием. Если для перезаписываемых объектов включено хранение версий, то на каждый шаг обновления в регистр сведений ВерсииОбъектов будет добавляться новая запись. Это не только замедляет работу, но и приводит к взрывному росту объема базы данных. На время обновления настоятельно рекомендуется временно отключить версионирование объектов через настройки программы.
Иногда конкретный обработчик, например, РегистрыНакопления.РасчетыСПоставщиками.ОбработатьДанныеДляПереходаНаНовуюВерсию, может войти в состояние, когда он потребляет ресурсы, но не продвигается по прогрессу. Разберем, как с этим бороться. Если вы видите по Журналу регистрации, что обработчик активен, но данные не меняются, возможно, он столкнулся с «битыми» ссылками или пустыми аналитиками (например, пустой объект расчетов).
В этом случае можно применить следующий алгоритм:
ОбработчикиОбновления.При массовом обновлении данных в ERP 2.5.22 нагрузка на TempDB возрастает многократно. Система активно использует временные таблицы для сопоставления старых и новых аналитик. Если файл TempDB расположен на медленном диске или имеет ограниченный размер авторасширения, это станет «бутылочным горлышком».
Посмотрим на лог транзакций (LDF). Даже если база находится в модели восстановления Simple, лог транзакций может переполниться до того, как произойдет контрольная точка (checkpoint). Убедитесь, что на диске достаточно места для роста лога, превышающего размер самой базы в 1.5–2 раза на период глобальных обновлений.
Для сокращения времени простоя рабочей базы рекомендуем выполнить следующие шаги:
1. Отключение итогов. Рассмотрим возможность отключения итогов для наиболее нагруженных регистров перед запуском обновления. Это позволит системе не пересчитывать агрегаты при каждой записи строки. После завершения всех обработчиков итоги нужно будет включить и пересчитать заново.
2. Управление количеством потоков. В ERP количество одновременно работающих фоновых заданий обновления регулируется в регистре Параметры работы программы. Не всегда «больше» означает «быстрее». Для тяжелых переходов на SQL Server 2019 оптимальным может быть 2–4 потока, чтобы избежать Deadlocks (взаимных блокировок).
3. Использование замера производительности. Если вы видите, что прогресс замер, включите замер производительности на сервере для фонового задания. Проанализируем полученные данные: если 90% времени тратится на метод Записать(), значит проблема в индексах SQL или подписках. Если время уходит на расчеты в коде — возможно, стоит оптимизировать алгоритм выборки данных.
Пример кода для программной остановки или сброса статуса обработчика (использовать в консоли кода):
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| Обработчики.ИмяОбработчика
|ИЗ
| РегистрСведений.ОбработчикиОбновления КАК Обработчики
|ГДЕ
| Обработчики.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыОбработчиковОбновления.Выполняется)";
Результат = Запрос.Выполнить().Выгрузить();
Для Каждого Строка Из Результат Цикл
Менеджер = РегистрыСведений.ОбработчикиОбновления.СоздатьМенеджерЗаписи();
Менеджер.ИмяОбработчика = Строка.ИмяОбработчика;
Менеджер.Прочитать();
Если Менеджер.Выбран() Тогда
Менеджер.Статус = Перечисления.СтатусыОбработчиковОбновления.Приостановлен;
Менеджер.Записать();
КонецЕсли;
КонецЦикла;
Подводя итог, отметим, что обновление ERP с 2.5.17 на 2.5.22 требует тщательной подготовки инфраструктуры. Сочетание настройки MAXDOP, очистки базы от расширений и контроля над специфическими обработчиками позволит успешно завершить переход без потерь данных и бесконечных ожиданий.