Долгая запись в регистр сведений из-за механизма авторегистрации

Logo_1c_8_expert

Всем привет!

Столкнулся я с одной интересной задачей оптимизации, которая была успешна решена. Ниже хочу поделиться с вами опытом. 🙂

 

 

 

 

Итак, конфигурация ЗУП 2.5, проблема – большое время проведения документа «Табель учета рабочего времени».

Приступаем! Чтобы понять в каком именно месте «тормозит», используем старый добрый замер производительности.

dolgaya-zapis-v-rs-iz-za-avtoregistracii-001

Что же мы видим из данного замера производительности? А видим мы, что первые две строчки в сумме составляют 74% от общего времени, а это 535 секунд!

Давайте посмотрим, что и куда записывается.

Итак, первое место:

dolgaya-zapis-v-rs-iz-za-avtoregistracii-002

И второе:

dolgaya-zapis-v-rs-iz-za-avtoregistracii-003

Проблема проявляется при записи в непериодический независимый регистр сведений «Графики работы по видам времени». Казалось бы все! Запись мы оптимизировать не можем, но расчетный путем стало понятно, что запись одной
строки занимает около одной секунды! Это непростительно много при отдыхающем то железе! Обратившись к нашему эксперту, Дмитрию Козиенко, с этим вопросом было принято решение заглянуть в SQL Server Profiler.

Вот что было найдено:

После записи основной таблицы регистра, происходила запись в таблицу InfoRgChngR11473. Это таблица регистрации изменений, которая используется, если объект входит хоть в один план обмена.

dolgaya-zapis-v-rs-iz-za-avtoregistracii-004

Теперь мы знаем, что запись происходит не только в основную таблицу регистра! Давайте узнаем точное время записи таблицу InfoRgChngR4547. Для этого в SQL Server Profiler необходимо получить таблицу трассировки по событию RPC Completed, далее сохраняем ее и получаем данные из трассировки запросами. Для данной трассировки я не стал использовать документ, в котором 250 строк, т.к. собрать такую трассировку достаточно проблематично, а взял документ с тремя строками табличной части. Трассировка собрана и сохранена, переходим к запросам!

Запрос первый:

dolgaya-zapis-v-rs-iz-za-avtoregistracii-005

Данным запросом я получил общее время записи. Т.е. время на обработку обоих таблиц. Обращаю ваше внимание, что время выводится в микросекундах.

Таким образом, чистое общее время составило 2,26 секунды.

Идем далее, вторым запросом уже получаем время записи в таблицу InfoRgChngR4547:

dolgaya-zapis-v-rs-iz-za-avtoregistracii-006

Время составило 1,58 секунды, это 70% от общего времени!!!

Далее, заглянув таблицу, стало понятно, что она совсем не маленькая:

dolgaya-zapis-v-rs-iz-za-avtoregistracii-007

В таблице регистрации на обмен 3155744 строк. Вообще в таблице регистрации не должно быть столько данных, она должна очищаться после каждого успешного обмена, но тут дала о себе знать специфика обмена у данного клиента.

Может затруднения возникают из-за «толстой» таблицы, давайте ее очистим и повторим трассировку!!!

dolgaya-zapis-v-rs-iz-za-avtoregistracii-008

Как видно, время на запись в таблицу регистрации изменений почти не изменилось. Очистка таблицы не помогла!

Продолжаем искать решение проблемы.

Исключаем наш регистр сведений «Графики работы по видам времени» из состава планов обмена и делаем замер производительности.

dolgaya-zapis-v-rs-iz-za-avtoregistracii-009

Теперь таблица InfoRgChngR4547 не используется, и время записи сократилось примерно на те самые 70%! В рамках данной задачи вопрос решен, т.к. записи регистра в обмене не участвуют, а заполняется отложенным проведением.

Но в целях эксперимента включаем регистр сведений «Графики работы по видам времени» в состав планов обмена, но выключаем авторегистрацию. Делаем замер.

dolgaya-zapis-v-rs-iz-za-avtoregistracii-010

Как видно второй и третий замер отличается незначительно!

Подведем итог: проблема возникает именно при авторегистрации, а конкретно когда платформа обрабатывает таблицу регистрации изменений в объекте для планов обмена. Вообще достаточно странно, что механизм платформы так медленно отрабатывает. Было решено убедится в этом. Для проверки на том же самом железе развернул демо базу такого же релиза, включил РИБ, сделал замер. И все подтвердилось, опять большое время записи! Замерил на разных платформах на 8.2 и 8.3 результат одинаков.

Что касается самой проблемы, то вижу ее решение только средствами 1С. Нужно отойти от механизма авторегистрации, возможно сделать отложенную регистрацию объекта. Ну это уже зависит от спецификации вашей задачи…

Спасибо за внимание!  🙂

Помогла ли вам данная статья?
Да, спасибо, помогла.
Немного помогла.
Совсем не помогла.
Не то, что я искал(а).

P.S. Смотрите также:

  • Заметки с фронта оптимизацииЗаметки с фронта оптимизации Добрый день, друзья! Сегодня я вам расскажу историю про оптимизацию типового запроса УПП при восстановлении последовательности расчетов. Будет много букв, но интересно. Оптимизировать […]
  • Получение данных через точку от полей составного типа в запросеПолучение данных через точку от полей составного типа в запросе Друзья, добрый день! Сегодня мы поговорим с вами о таком замечательном явлении как получение данных через точку от полей составного типа в запросе. Конечно же, все мы знаем, что так […]
  • История одной оптимизацииИстория одной оптимизации Всем привет. Сегодня я вам расскажу историю одной оптимизации или как я восстанавливал нормальную работу в […]
  • Общий подход к оптимизацииОбщий подход к оптимизации Добрый день, друзья! Сегодня я хочу рассказать вам про общий подход к решению проблем производительности. Эта статья будет небольшим практическим пособием «С какой стороны подойти к […]
  • Блокировки данных в 1С (Записки эксперта — Часть 3)Блокировки данных в 1С (Записки эксперта — Часть 3) Сегодня речь пойдет о блокировках данных в 1С.   В видео использованы материалы статей: Материалы в рубрике Эксперт 1С Все видео из цикла «Записки […]
Запись опубликована в рубрике Эксперт 1С с метками , . Добавьте в закладки постоянную ссылку.


Добавить комментарий

Ваш e-mail не будет опубликован.