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

19.10.21

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

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

Скачать файл

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

Наименование По подписке [?] Купить один файл
Скрипты для вывода топовых вызовов:
.zip 6,34Kb ver:1.0
2
2 Скачать (3 SM) Купить за 2 450 руб.

Дано

База 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С v8.3 Бесплатно (free)

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

06.06.2024    9256    Evg-Lylyk    61    

44

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

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

13.03.2024    5096    spyke    28    

49

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

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

13.03.2024    7572    vasilev2015    20    

42

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024    12417    241    ZAOSTG    80    

115

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024    5669    glassman    18    

40

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024    14010    doom2good    49    

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