Оптимизация запуска "1С:Управление холдингом" под пользователем с ролью "Налоговый мониторинг"

19.10.21

База данных - HighLoad оптимизация

Опыт оптимизации запуска базы «1С:Управление холдингом» под пользователем с ролью «Налоговый мониторинг».

Файлы

ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.

Наименование Скачано Купить файл
Скрипты для вывода топовых вызовов:
.zip 6,34Kb ver:1.0
2 3 400 руб. Купить

Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний

Оформите подписку на компанию для решения рабочих задач

Оформить подписку и скачать решение со скидкой

Дано

База 1С:Управление холдингом, редакция 3.1 (3.1.14.15)

В базе создан пользователь 1, которому присвоена роль «Налоговый мониторинг», база открывается более 5 минут.

У других пользователей база открывается в разы быстрее: около 30 секунд.

СУБД: PostgreSQL 12.7.

 

Задача

Необходимо оптимизировать запуск под пользователем 1.

 

Замер производительности

Серверная отладка включена, работает. В замере производительности суммарное время показывает около 30 секунд, то есть основное время (причина) отсутствует в замере — да, к сожалению, такое бывает, на практике встречалось много раз.

 

RLS

RLS в роли "Налоговый мониторинг" есть только к справочнику "Банковские счета".

С отключенным RLS запуск такой же медленный.

 

Тестовая база

Тестовая база развернута на СУБД MSSQL Server.

На СУБД MSSQL Server запуск прерывается с другой ошибкой: «Обработчик запросов исчерпал внутренние ресурсы, и ему не удалось предоставить план запроса. Это редкое событие, которое может происходить только при очень сложных запросах, которые обращаются к очень большому числу таблиц или секций. Упростите запрос.»

 

 

Ошибка на MSSQL может быть связана с одинаковым одним и тем же источником, а может и с другим и по другой причине, поэтому для экономии времени и для точности придется прибегнуть к анализу технологического журнала (ТЖ).

 

Анализ ТЖ

 

1) Настроен сбор следующей настройкой

 
logcfg.xml

 

2) Воспроизведен медленный запуск базы.

 

3) Выведены топовые вызовы:

    - "Топ CPU вызовов";

    - "Топ суммарно длительных вызовов";

    - "Топ длительных вызовов";

    - "Топ пиков потребления памяти";

    - "Топ запросов с временем".

 

Во всех топах прослеживается один совпадающий вызов, на который следует обратить особое внимание:

 
Топ CPU вызовов 
 
Топ суммарно длительных вызовов
 
Топ длительных вызовов 
 
Топ пиков потребления памяти 
 
Топ запросов с временем

 

Итак, в 18:40:39 завершился вызов, который занял объем памяти 266849141 bytes.

266849141 bytes = 254 Мб потребления памяти за один клиент-серверный вызов - это значительно много, такой объем приводит к ожиданию, по сути мы ждем скачивание данных.

Так как "Топ запросов с временем" показал длительность 412 секунд = 6 минут 52 секунды, то основное ожидание происходит из-за запроса на СУБД PostgreSQL.

Запрос, действительно большой и сложный, в запросе присутствуют слова SDBL_DUMMY, SDBL_DUAL, означающие использование RLS.

 

 
Текст запроса SQL (Внимание! Очень большой текст)

 

Проанализирован программный код указанного участка.

 

Оказалось, в обработке НалоговыйМониторинг в форме РегламентированнаяОтчетность есть динамический список, источником которого является произвольный запрос, извлекающий данные из регистра ЖурналОтчетовСтатусы с условием "Ссылка.ПометкаУдаления = ЛОЖЬ".

 

 

 

В регистре ЖурналОтчетовСтатусы у поля Ссылка тип произвольный (ДокументСсылка, СправочникСсылка), в результате образуется множество левых соединений с разными таблицами.

 

 

 

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

 

Правка оказалось простой: в условии вместо "РегистрСведенийЖурналОтчетовСтатусы .Ссылка.ПометкаУдаления = ЛОЖЬ" заменено на "РегистрСведенийЖурналОтчетовСтатусы.ПометкаУдаления = ЛОЖЬ".

 

 

Результат

В результате изменения запроса динамического списка база под пользователем 1 теперь запускается в течение 15 секунд.

 

Во вложении скрипты для вывода указанных топовых вызовов с помощью GitBash.

Вступайте в нашу телеграмм-группу Инфостарт

оптимизация код ускорение запуск RLS налоговый мониторинг

См. также

HighLoad оптимизация Программист 1С 8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Использование оператора «В» для полей или данных составного типа (например, Регистратор) может приводить к неочевидным проблемам.

10.11.2025    7035    ivanov660    48    

52

HighLoad оптимизация Программист 1С:Предприятие 8 1C:ERP Бесплатно (free)

Приведем примеры использования различных в динамических списках и посмотрим, почему это плохо.

18.02.2025    9296    ivanov660    39    

61

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024    11731    ivanov660    13    

64

HighLoad оптимизация Программист 1С:Предприятие 8 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024    18192    Evg-Lylyk    73    

46

HighLoad оптимизация Программист 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024    8892    spyke    29    

54

HighLoad оптимизация Программист 1С:Предприятие 8 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024    12328    vasilev2015    22    

47
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. МихаилМ 20.10.21 18:51 Сейчас в теме
сколько времени заняло поиск и исправление ошибки ?
2. info1i 246 20.10.21 19:23 Сейчас в теме
(1) Трудно сказать, так как задача решалась в паре с разработчиком. Я парсил ТЖ, напарник смотрел код по моим находкам.
Я потратил 3-4 часа; напарник не знаю, сколько потратил; но тоже около того.
3. МихаилМ 20.10.21 19:33 Сейчас в теме
(2) разделение труда - сила. очень быстро по моим меркам.
4. info1i 246 21.10.21 12:18 Сейчас в теме
(3) Нужно сказать, что на экзамене по эксперту для решения подобных задач на все про все выделяют около 1 часа, максимум 2 - это одна из причин, почему мне не удается сдать экзамен.
5. dctvghbdtn 27.10.21 19:06 Сейчас в теме
Для отправки сообщения требуется регистрация/авторизация