В предыдущем материале о промежуточных конфигурациях 1С мы рассказали, что это такое и как их правильно подбирать. В этой статье поговорим про оптимизацию отработки промежуточных. По опыту десятков проектов сложного обновления 1С наша команда выделила этой работе отдельный этап, разберемся с ним подробнее.
Nota bene: если обновление рабочей базы не укладывается в технологическое окно, например, предприятие не может остановить свою работу даже на выходные и праздники — есть ещё вариант обновления через копию базы, но про такой способ мы расскажем в другом материале.
Регулярные вопросы оптимизации промежуточных конфигураций, на которые нельзя ответить положительно :(
Частые вопросы, которые мы слышим перед стартом проекта: можно ли все промежуточные конфигурации совместить в одну? Станет ли работать быстрее? Проще ли будет обновить?
К сожалению, нет. Во-первых затраты на создание и, особенно, тестирование такой конфигурации будут существенно больше. Поскольку все обработчики в ней должны будут выполняться последовательно (в более поздних версиях нужны будут данные, которые обрабатываются в более ранних версиях), мало что можно будет распараллелить, поэтому выигрыш во времени будет минимальный, а риск появления ошибок возрастает.
Еще регулярный вопрос: можно ли перескочить ключевые релизы и обновиться сразу на последний, это же будет быстрее? Иногда — да, через некоторые релизы можно «перепрыгивать» без потери данных, и иногда даже можно сразу ставить актуальную версию, но порекомендовать список ключевых релизов мы можем только в конкретном случае. Более подробно про выбор обязательных ключевых релизов при обновлении мы писали в материале «Промежуточные конфигурации, часть 1: зачем они нужны и как их правильно подобрать для обновления нетиповой 1С».
В общем случае рекомендуем придерживаться порядка обновления с сайта releases.1c.ru.
Что же делать? В первую очередь — определить проблемные места обновления.
Поиск проблемных мест обновлений в нетиповых конфигурациях
Обновление базы на новую версию конфигурацию происходит в 3 этапа:
- реструктуризация,
- выполнение основных обработчиков в монопольном режиме,
- выполнение отложенных обработчиков.
Этап реструктуризации можно ускорить только одним способом: использовать оптимизированный механизм реструктуризации v2 — о нашем опыте в следующей статье.
Этап выполнения основных обработчиков можно ускорить распараллеливанием, либо переносом обработчиков в другие промежуточные, если это необходимо, а ошибки искать только с помощью отладки. Как правило это ошибки, возникшие из-за доработок конфигурации.
Этап выполнения отложенных обработчиков можно ускорить разными способами, в зависимости от найденных проблем.
Способы оптимизации отложенных обработчиков
Рассмотрим способы, за счет которых можно «прогнать» промежуточные конфигурации быстрее.
Изменение приоритета обработки данных
Для ускорения выполнения отложенных обработчиков обновления можно изменить приоритет обработки данных с «Работа пользователей» на «Обработка данных» — в этом случае запускается обработка сразу всех данных, а не итерационно. Если в конфигурации доступно многопоточное выполнение обработчиков, то появляется возможность установить несколько потоков обновления.
Рекомендация от 1С по количеству потоков приведена на скриншоте.
Обработка «Результат обновления программы» с рекомендациями 1С
Изменение порядка выполнения обработчиков обновления
При выполнении обновления в многопоточном режиме одна из частых проблем — обработчики обновления одной очереди пытаются обработать объекты, которые должны быть сформированы другой очередью.
Рассмотрим эту проблему на примере обновления «1С:ERP/1С:КА» с редакции 2.4 на 2.5 и «1С:УТ» с редакции 11.4 на 11.5. В процессе выполнения обработчиков генерируются новые объекты — «Объекты расчетов». Параллельно стартуют другие обработчики, которые ищут объекты расчетов для заполнения в своих обрабатываемых данных.
Не все объекты расчетов успевают сгенерироваться к моменту, как они понадобятся обработчикам заполнения. В таких случаях обработчик оставляет необработанные данные для следующей попытки. В журнале регистрации при этом можно увидеть ошибки вида «Объект расчетов не найден». А пока не выполнятся обработчики заполнения — не выполняться другие зависящие от них обработчики. Они будут отрабатывать в цикле много раз, что приведет к общему замедлению выполнения обновления.
В этом случае может помочь смена порядка выполнения обработчиков. Например, в режиме предприятия вручную приостановить все обработчики обновления регистров накопления, регистров сведений, которым требуются объекты расчетов, чтобы возобновить их только после того, как будут выполнены все обработчики по генерации объектов расчетов.
Вручную это можно сделать через регистр сведений «Обработчики обновления». Выбрать нужный обработчик, зайти в него, установить статус «Приостановлен», записать и закрыть.
Выбор обработчиков обновления
Выбор статуса конкретного обработчика обновления
Возобновить обработчик можно через эту же форму, установив статус «Выполняется».
Если это помогло ускорить обновление, избавило от ошибок с объектами расчетов по журналу регистрации, то можно реализовать приоритетность выполнения обработчиков в коде следующим образом:
- Добавить в конфигурацию или в расширение функционал определения статуса выполнения обработчиков, которые генерируют объекты расчетов.
- В обработчики обновления регистров, которым требуются объекты расчетов, внести доработку, которая не разрешит запускаться обработчику, пока не будут сгенерированы все объекты расчетов.
Пример кода:
Функция ПроверитьВыполнениеОбработчиковОбновления() Экспорт
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| ОбработчикиОбновления.ИмяОбработчика КАК ИмяОбработчика
|ИЗ
| РегистрСведений.ОбработчикиОбновления КАК ОбработчикиОбновления
|ГДЕ
| ОбработчикиОбновления.Статус = ЗНАЧЕНИЕ(Перечисление.СтатусыОбработчиковОбновления.Выполняется)
| И ОбработчикиОбновления.ИмяОбработчика В (&МассивИменДляПроверки)";
Запрос.УстановитьПараметр("МассивИменДляПроверки", ПолучитьМассивИмен());
РезультатЗапроса = Запрос.Выполнить();
Если Не РезультатЗапроса.Пустой() Тогда
Возврат Истина;
КонецЕсли;
Возврат ЛОЖЬ;
КонецФункции
Функция ПолучитьМассивИмен()
МассивИмен = Новый Массив;
МассивИмен.Добавить("Справочники.Контрагенты.СгенерироватьОбъектыРасчетов");
Возврат МассивИмен;
КонецФункции
Процедура ОбработатьДанныеДляПереходаНаНовуюВерсию(Параметры) Экспорт
Если МойМодуль.ПроверитьВыполнениеОбработчиковОбновления() Тогда
Параметры.ОбработкаЗавершена = Ложь;
Возврат;
КонецЕсли;
<продолжение типовой процедуры>
Пересчет итогов, отключение использования итогов
Если в регистрах в текущих итогах накопилось много нулевых строк (30-50% от общего числа) — есть смысл пересчитать итоги перед тем, как устанавливать обновление.
Нулевые строки возникают, когда количество приходов и расходов по набору значений измерений одинаково, например, списали все, что поступило в этом месяце. Платформа не удаляет такие записи и со временем количество нулевых записей в регистре растет.
Запросы к регистрам будут работать быстрее, если итоги будут актуальными, потому что при расчете значения на дату, запрос сначала обратится к таблице итогов, там найдет остаток рассчитанных итогов и к нему прибавит (или отнимет) обороты до даты, указанной в запросе. Если итоги будут неактуальными, то запросу придется сканировать больше строк оборотов и остатков для получения нужного значения, что приведет к замедлению.
Пересчитать все итоги можно через конфигуратор. Процесс охватывает все периоды по всем регистрам. Эта операция производится в монопольном режиме и нередко занимает много времени.
Пересчет итогов через Конфигуратор
Ещё есть вариант выборочно пересчитать итоги только по нужным регистрам. Для этого в режиме предприятия нужно открыть стандартную обработку «Управление итогами и агрегатами». В ней перейти в режим полных возможностей.
Ссылка на режим полных возможностей на вкладке «Управление итогами»
Найти в списке итогов нужный регистр и пересчитать итоги через меню «Пересчет».
Пересчет итогов на вкладке «Управление итогами»
Иногда обновление идет долго из-за того, что обработчики обновления обращаются к данным регистров — информации в них бывает много, а при каждой записи обновленных данных платформой выполняется расчет итогов этого регистра.
Для ускорения обработки данных можно отключить использование итогов, делается это двумя способами.
Во-первых, вручную, через стандартную обработку «Управление итогами и агрегатами». Найдите в списке итогов нужный регистр и отключите итоги через меню «Итоги» - «Выключить использование итогов» и «Текущие итоги» - «Выключить использование текущих итогов».
Выключение итогов
После окончания отложенных обработчиков необходимо включить использование итогов обратно.
Второй способ: программно, используя методы платформы «УстановитьИспользованиеТекущихИтогов» и «УстановитьИспользованиеИтогов». В начале выполнения медленного обработчика отключить использование итогов, в зависимости от того, какие итоги включены по регистру. В конце выполнения обработчика, когда обработка всех данных будет завершена, включить использование итогов.
Nota bene: важно понимать, что при отключении итогов будут недоступны таблицы итогов (виртуальные таблицы остатков и оборотов), при обращении к ним возникнет исключительная ситуация. Отключайте их, только если в обработчике обновления не используются виртуальные таблицы.
Отключение ненужных обработчиков
При обновлении на несколько промежуточных конфигураций подряд, в них могут выполняться одни и те же обработчики, поэтому для ускорения такой обработчик можно отключить в одной из промежуточных. Это касается обработчиков старых версий, где они не всегда учитывают уже обработанные данные.
Если в конфигурации было частичное обновление, то, возможно, какие-то данные уже актуальны и нет необходимости в их обновлении. Такие обработчики можно отключить, предварительно поставив в процедуру проверку, что для текущего элемента значение уже заполнено корректно в соответствии с новой логикой.
Этот способ требует изучения данных в базе перед обновлением.
Исключение объектов из регистрации, снятие с регистрации
Способ применим, когда обработчики выполняются, но прогресс выполнения не идет. Если по отчету о прогрессе отложенного обновления к обработке осталось несколько объектов, которые «зависли», то можно найти их с помощью типовой обработки «Регистрация изменений для обмена данными».
Часто встречающиеся проблемы с такими объектами:
- объект может быть некорректно заполнен, вследствие чего не проведен и\или помечен на удаление, а в тексте обработчика отсутствуют проверки для корректной обработки таких объектов;
- обработчик обновления не может обработать объект, в котором не заполнены реквизиты, обязательные к заполнению;
- в обработчике обновления не предусмотрена обработка этого типа объекта, например, документ «КорректировкаРегистров»;
- зарегистрированы объекты с битыми ссылками «Объект не найден», а в обработчике не предусмотрена обработка таких объектов.
В соответствии с найденной проблемой нужно выбрать вариант решения.
Первый — исправить данные в базе:
- Вручную, заполнив корректно все необходимые поля. Но сделать это можно не всегда — данные могут находиться в закрытом периоде, который нельзя открывать.
- Либо создав обработку, с помощью которой перед обновлением заполнить недостающие данные и аккуратно записать объект в режиме обмена данными и без проведения.
Второй — не регистрировать такие объекты к обновлению. Как правило для этого нужно внести правки в обработчик регистрации.На скриншоте ниже показан пример исключения из регистрации к обновлению определенных документов, также в этом обработчике пришлось ставить условие, чтобы не попадали объекты с битыми ссылками «ОбъектНеНайден».
Отмена регистрации объекта к обновлению
В некоторых случаях данные к обновлению помечаются по следующему принципу: обрабатываются все регистраторы регистра. Если в регистраторы добавлены свои документы, то они тоже зарегистрируются к обработке. Если обрабатывать их не нужно, то можно сделать исключение в обработчике.
Пример исключения документа из обработки
Из-за особенностей данных в базе типовые запросы в обработчиках обновления, формирующие выборку данных для обработки, могут возвращать дубли строк. Далее обработчик пытается обновить объекты из выборки и происходит зацикливание. В таких случаях может помочь доработка запроса — добавление группировки, которая избавит от дублей.
Распараллеливание обработчиков
Долго идущие обработчики можно распараллелить, разделить на несколько потоков, выполняющихся в фоновых заданиях. Отдельная тема, которую, возможно, опишем в других материалах.
Исправление запросов
Иногда медленная работа обработчиков обновления связана с долгим выполнением запроса. Причин может быть много: слишком большая выборка данных, слишком маленькая выборка данных, неоптимальное написание запроса (избыточные соединения, соединения по полям составного типа и многое другое), или даже просто «кривые» данные в базе.
При этом в процессе выполнения обновления из отложенных обработчиков не всегда возможно достать запрос в консоль запросов и проанализировать его на таких же входящих данных, как он выполняется в базе.
В таких случаях можно запустить отладку с параметром «/С РежимОтладки». В этом режиме все длительные операции выполняются сразу, без запуска фонового задания (кроме отдельных операций, которые всегда должны выполняться в фоновом задании, например, обновление параметров работы программы конфигурации без учета расширений конфигурации).
Запуск приложения с параметром запуска «РежимОтладки»
Анализ запросов требует хорошего уровня знаний. Если в таблицах не настроено индексирование или оно настроено неправильно (неоптимально, не под этот конкретный запрос), или сделаны ошибки в написании, план запроса вынужден вызывать операции сканирования всей таблицы всех страниц данных — операции Scan, Index Scan, Clustered Index Scan, Key Lookup, все эти же виды сканирования в цикле Nested Loops, конструкция Clustered Index Seek или Index Seek: Seek, поиск по одному индексированному полю Where, поиск по всем остальным полям без учета индекса и другие — что и вызывает замедление.
В общем случае задачей разработчика является максимальное избавление плана запроса от операций сканирования, то есть от количества чтений диска. Решать эту задачу надо с помощью настраивания статистики, правильного использования индексирования, правильного написания запросов с оглядкой на данные в базе (их количество, их типы, частота использования, и.т.д).
На ИТС есть информация о том, какими должны быть оптимальные запросы:
- Общие требования к запросам: https://its.1c.ru/db/v8std/browse/13/-1/26/28.
- Типичные причины неоптимальной работы запросов и методы оптимизации: https://its.1c.ru/db/metod8dev/content/5842/hdoc.
Nota bene: поскольку в проектах обновления мы гораздо чаще правим чужие запросы (вендора или клиента), то выработали правило, что не стоит оптимизировать все, что попадается. По-настоящему оптимальный запрос не только составлен «правильно и красиво, как написано на ИТС», но и учитывает особенности данных в базе клиента и используемой СУБД. Судить об оптимальности запроса можно только по замерам и плану запроса в каждом конкретном случае!
***
В следующей части расскажем несколько примеров «из реальной жизни» про оптимизацию промежуточных конфигурации на наших проектах обновления.
