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

20.07.22

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

Еще один интересный пример оптимизации производительности ERP. Описываем решение проблемы подробно по шагам.

В данной статье мы изложим некоторую примерную последовательность действий по выявлению проблемы производительности и ее поэтапному решению (с картинками и комментариями). Думаю, что будет особенно интересно новичкам, а также тем, кто планирует столкнуться с СУБД Postgres или уже ведет активную работу в этом направлении. 

Структура статьи:

  • Введение и постановка задачи
  • Ищем точку возникновения
  • Получаем исполняемый текст запроса
  • Подготавливаем исходный запрос в консоли запросов
  • Анализируем план исходного запроса
  • Оптимизация шаг 1. Исправление очевидной ошибки
  • Оптимизация шаг 2. Декомпозиция запроса
  • Заключение

 

Введение и постановка задачи

 

Для решения этой задачи нам понадобится:

  • конфигурация «Мониторинг производительности» - в ней будем оценивать количество событий, точки возникновения, собирать статистику онлайн;
  • доступ к целевой конфигурации ERP - в ней будем смотреть проблемный код и получать текущий запрос;
  • консоль запросов – моделирование, оптимизацию;
  • конвертер текстов SQL в представления 1С – преобразовывать нечитаемое представление в читаемое тестов и планов, создавать графическое представление плана запросов;
  • доступ к базе Postgres для проверки некоторых гипотез (опционально).

Те счастливчики, у которых есть конфигурация ERP, УТ, КА с хорошим набором данных смогут повторить эксперимент у себя. На демонстрационной базе прочувствовать всю глубину рассматриваемой проблемы не получится, но посмотреть планы и увидеть результат работы можно попробовать. 

 

Исходная информация:

Проблема проявилась в документе установка цен номенклатуры у известных пользователей (есть ФИО) конфигурации ERP 2.4. Нам предстоит выявить проблему и исправить эту ситуацию. 
 

Что мы будем делать?

Мы найдем точку возникновения проблемы, получим текст запроса и будем отлаживать в консоли запросов, исправляя проблему. Раз, два, три... Поехали!

 

I) Ищем точку возникновения

 

Для того чтобы было удобно и просто искать места проблем, мы рекомендуем установить и настроить конфигурацию "Мониторинг производительности". Это удобно cделать на продуктовом  и на тестовом сервере. Если вы конечно не приверженец Old-school и любите работать в каком-нибудь парсере руками.

Т.к. у нас это уже настроено, то мы сразу посмотрим картинку из журнала длительных замеров. Поставим фильтр по длительности, пользователю или текстовому вхождению - это зависит от входящей информации по проблеме. В текущем случае будем фильтровать по вхождению «установка цен» в поле "context".

 

 

Система отобрала подходящие записи. И из картинки выше видно, что время подобных событий достигает иногда десятков минут, чуть чаще не более 10 с. Вообще разброс достаточно большой.

Давайте посмотрим где это происходит. Двойной клик по полю выделенной строки открывает отдельную вкладку с контекстом выполняемой операции.

 

 

Анализируем контекст:

  • Это процедура открытия документа "Установка цен номенклатуры". На это нам указывает команда "получить форму";
  • Это основная форма документа;
  • Проблема формируется запросом. Самая последняя позиция стека содержит команду "Запрос.Выполнить()";
  • Этот запрос похоже находится в модуле «УстановкаЦенСервер» - функция «ЗагрузитьТабличнуюЧастьТовары»;
  • Этот запрос расположен в строке «3907»;
  • Если мы посмотрим еще несколько записей журнала, то можем встретить вторую функцию «ЗагрузитьСтарыеЦеныНоменклатурыПредприятия», они имеют похожую структуру, но она выполняется обычно быстрее.

Давайте глазками посмотрим что это за запрос, как он выглядит и что из себя представляет. Поэтому переходим к следующей части.

 

II) Получим исполняемый текст запроса

 

Чтобы получить искомый текст нам необходимо выполнить набор простых действий:

  • Открываем конфигурацию;
  • В дереве метаданных находим общий модуль «УстановкаЦенСервер» и открываем его;
  • Переходим в точку выполнения запроса - это позиция «3907».  Для быстрого перехода к позиции нажимаем сочетания «Ctrl»+«G».
  • В итоге мы должны оказаться в функции «ЗагрузитьТабличнуюЧастьТовары».

 

 

Где-то чуть выше должен находиться нужный нам текст запроса их два, но нам нужен тот что используется для продажи. На первый взгляд, он довольно простой:

 
 Исходный текст запроса

 

Что про него можно сказать:

  • Это пакет, и он состоит из двух частей;
  • В первой загружается таблица данных и формируется временная таблица;
  • А во втором выполнятся выборка с учетом этих входных данных;
  • Проблема находится во второй части пакета, т.к. текст SQL представления начинается с ключевого слова "SELECT", а не "INSERT";
  • В нем есть несколько интересных параметров - «ТекстЗапросаКоэффициентУпаковки1» и «ТекстЗапросаКоэффициентУпаковки2», которые подставляются в программном коде следующим образом:
 
 Программное преобразование запроса (подстановка значения параметров "ТекстЗапросаКоэффициентУпаковки")

 

Мы не можем просто так взять текущий текст для его анализа в консоли. Поэтому будем получать собранный запрос в отладке. Далее действуем так:

  • Ставим точку останова в позиции «3907»;
  • Стартуем предприятие;
  • Открываем любой документ; 
  • Получаем текст запроса.

 

 

Соберитесь! Полный текст запроса приведен внутри свернутого спойлера. Если будете его смотреть, то делайте это аккуратно и без резких движений)

 
 Полный текст запроса

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

производительность оптимизация эксперт postgres

Вы можете заказать платную адаптацию этой статьи под ваши задачи на «Бирже заказов».

  • 0% комиссии — оплата напрямую исполнителю;
  • Исполнители любого масштаба — от отдельных специалистов до команд под проект;
  • Прямой обмен контактами между заказчиком и исполнителем;
  • Безопасная сделка — при необходимости;
  • Рейтинги, кейсы и прозрачная система откликов.

См. также

Инструментарий разработчика Роли и права Запросы СКД Программист Руководитель проекта 1С:Предприятие 8 Платные (руб)

Инструменты для разработчиков 1С 8.3: Infostart Toolkit. Автоматизация и ускорение разработки на управляемых формах. Легкость работы с 1С.

16500 руб.

02.09.2020    273067    1516    422    

1182

Работа с интерфейсом Анализ учета Мониторинг 1С:Предприятие 8 1С 8.3 1C:Бухгалтерия 1С:Бухгалтерия 3.0 1С:ERP Управление предприятием 2 1С:Управление холдингом 1С:Зарплата и Управление Персоналом 3.x 1С:Комплексная автоматизация 2.х 1С:Управление нашей фирмой 3.0 1С:Управление торговлей 11 Платные (руб)

Создайте свой функциональный интерфейс в любой конфигурации 1С с помощью расширения Infostart Dashboard. Настраивайте панели виджетов с метриками, индикаторами и показателями на начальном экране. Узнайте возможность внедрения подсистемы у себя в конфигурации с помощью бесплатной обработки "Анализ внедрения подсистемы 1С Infostart Dashboard"!

31720 руб.

27.03.2025    89304    65    44    

75

Инструменты администратора БД Корректировка данных Мониторинг Учет документов 1С 8.3 1С:Управление торговлей 10 1С:Розница 2 1С:ERP Управление предприятием 2 1С:Бухгалтерия 3.0 1С:Управление торговлей 11 1С:Розница 3.0 Платные (руб)

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

6100 руб.

11.06.2026    628    2    0    

4

Логистика, склад и ТМЦ Мониторинг Маркетплейсы Пользователь 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Платные (руб)

Расширение для 1С, которое автоматически «отлавливает» тарифы складов с наиболее выгодными коэффициентами для ваших товаров на маркетплейсе Wildberries. С помощью этого инструмента вы сможете легко находить и выбирать склады с лучшими условиями для максимизации своей прибыли. Удобная интеграция позволяет настроить регулярный поиск складов по выгодным коэффициентам в виде регламентного задания в 1С, что существенно экономит время и автоматизирует процесс принятия решений по размещению товаров. Всегда будьте на шаг впереди конкурентов и повышайте эффективность своего бизнеса с помощью «Ловца коэффициентов складов Wildberries»!

6100 руб.

14.11.2024    2458    1    0    

4

Мониторинг Анализ продаж 1С:Предприятие 8 1C:Бухгалтерия 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х 1С:Розница 3.0 Управленческий учет Платные (руб)

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

24400 руб.

11.11.2024    3102    1    0    

2

Учет доходов и расходов Логистика, склад и ТМЦ Маркетплейсы Мониторинг Пользователь 1С:Предприятие 8 1С:ERP Управление предприятием 2 1С:Управление торговлей 11 1С:Комплексная автоматизация 2.х Розничная и сетевая торговля (FMCG) Оптовая торговля, дистрибуция, логистика Управленческий учет Платные (руб)

Расширение модуля Synchrozon для удобного контроля габаритов на Ozon! Разработка позволяет мгновенно сравнивать установленные габариты товаров, с габаритами, указанными на Ozon, чтобы выявлять любые несоответствия. Поможет сократить расходы на логистику, гарантируя, что все данные о товарах остаются точными и актуальными.

5000 руб.

31.10.2024    2470    1    0    

3

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

Столкнулся с интересной ситуацией, которую хотел бы разобрать, ввиду её неочевидности. Речь пойдёт про использование функции запроса АВТОНОМЕРЗАПИСИ() и проблемы, которые могут возникнуть.

11.10.2024    22519    XilDen    39    

113
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. quazare 4011 20.07.22 18:19 Сейчас в теме
Я правильно понял, что в типовом запросе не было виртуальных проиндексированных таблиц и отсутствовал одно соединение по фильтру вид цены?

Ну тогда, вероятно в запросе нужно сделать уничтожение виртуальных таблиц после их использования?
3. ivanov660 4980 20.07.22 21:57 Сейчас в теме
(1)
1. Да относительно фильтра "ВидЦены". Типовой запрос приведен в спойлере "Исходный текст запроса" и в нем отсутствует в условии фильтра поле "ВидЦены", есть только "Характеристика" и "Номенклатура", а этого не достаточно для оптимальной работы.
2. Не понял что такое виртуальная проиндексированная таблица. Попробую ответить так: мы разбили запрос на две части и в первой создали временную таблицу фактически для того чтобы "упростить жизнь" планировщику запросов. Postgre в отличии от MS SQL не такой "умный" и работает хуже. На СУБД MSSQL такой деградации производительности из-за отсутствия фильтра внутри виртуальной таблицы не происходит. Можно проверить этот факт самостоятельно.
3. Обычно удаление временных таблиц необходимо делать, когда в пакете будет использоваться таблица с таким же именем. В остальных случаях платформа подчищает хвосты самостоятельно.
2. gzharkoj 596 20.07.22 21:39 Сейчас в теме
Нарушены два требования 1с:
1. Все отборы,которые могут установлены виртуальных таблицах должны находится в параметрах виртуальной таблицы. В запросе отбор по Виду цены находился в левом соединении, а не в виртуальной таблице
2. Не использовать соединения с подзапросами, рекомендация сформировать отдельную временную таблицу. По факту запрос к виртуальной таблице СрезПоследних цен развернется в подзапрос, поля соединения не будут проиндексированы у подзапроса. В целом так можно делать, когда количество результирующих строк виртуальной таблицы не много, до 1к, на больших данных будут просадки, что автор и показал с ~5к позициями товаров.
Дмитрий74Чел; quazare; ardn; ivanov660; +4 1 Ответить
10. nicxxx 257 21.07.22 11:21 Сейчас в теме
(2)
2. Не использовать соединения с подзапросами, рекомендация сформировать отдельную временную таблицу.

Перейти на MSSQL, там это проблема решена :)
11. ivanov660 4980 21.07.22 11:24 Сейчас в теме
(10)
1. Не совсем так, подобную проблему вы можете словить и в этой СУБД. Она "умнее" да, но не везде и всегда.
2. Официально купить MS SQL на текущий момент вроде нет возможности для российских компаний.
4. VSvintsov1 21.07.22 05:03 Сейчас в теме
автор предлагает повторить это тестирование на стандартных конфигурациях. - верно ли я понял , что авторство запроса с конструкцией:
.....
ИЗ
	ВременнаяТаблицаТовары КАК ВременнаяТаблицаТовары
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
....


принадлежит разработчикам типовых конфигураций ?
5. ivanov660 4980 21.07.22 08:58 Сейчас в теме
(4) Да, и в этом нет ничего не обычного.
Дмитрий74Чел; +1 Ответить
6. cdiamond 237 21.07.22 09:03 Сейчас в теме
(4) Видимо так. Но однозначно говорят что это криминал только вроде на курсе специалиста по платформе. На курсе по эксперту уже с оговорками и условиями ) Всё зависит от объема данных в тех или иных таблицах - здесь же очевидно авторы конфигурации не рассчитывали что номенклатуры будут десятки тысяч и на все будут устанавливать цены. В целом таких непредусмотренных ситуаций в ERP 2.4 довольно много и это отличное поле для оптимизаторов. Есть еще другая сторона вопроса - злоупотребление временными таблицами, в котором 1С является чемпионом в нашей галактике, очевидно что загонять миллионы строк во временную таблицу тоже решение так себе, за которое нужно платить большими объемами оперативной и твердотельной памяти.
8. ivanov660 4980 21.07.22 09:44 Сейчас в теме
(6)
1. Предположение что в продуктовой базе компании, которая будет использовать ERP, номенклатуры будет не более чем в демонстрационной базе - это, на мой взгляд, не профессиональный подход. ERP позиционируется как конфигурация для больших компаний.
2. Если в ситуации, когда нет выбора, то использовать или не использовать временную таблицу, решается практически как в данной статье. Думаю, что миллион строк при возможности работы за 3 с - это лучшее решение, чем виртуальная таблица и 1 час на открытие каждого документа (если вы так переживаете за время жизни жесткого диска, то можете сделать RAM диск под tmp файлы). С другой стороны чтобы избежать этого можно заставлять пользователя делать 100 документов для установки цен, но такой подход - это курам на смех.
12. TMV 1 21.07.22 23:06 Сейчас в теме
(8) Бывают ли у вас документы с количеством строк записей в наборе по какому-либо регистру более 100 тысяч?
9. ivanov660 4980 21.07.22 09:55 Сейчас в теме
(6) В некоторое ближайшее время, мы планируем выложим обработку, которая позволит из демонстрационной базы в относительно "сжатые сроки", сделать нормальную базу для проверки ее работы при больших объемах данных. Пока мы ее тестируем и проверяем свои задачи, но за 2-е суток удалось создать оптимальное число, законченных цепочек.
Вот тут и можно будет развернуться для проверок тех или иных списков и запросов, идей.
Прикрепленные файлы:
Дмитрий74Чел; ef42; CAV; +3 Ответить
17. Дмитрий74Чел 250 28.07.22 16:51 Сейчас в теме
7. Serg O. 337 21.07.22 09:38 Сейчас в теме
Спасибо, статья как всегда очень круто оформлена.
Максимально подробно и с красивыми картинками.
Огромный +
Sejix; Jimbo; user1559729; ubnkfl; ardn; ivanov660; +6 Ответить
13. TMV 1 21.07.22 23:09 Сейчас в теме
(0) Имеет ли значение порядок в секции Индексировать в запросе формирования временной таблицы? В регистре сведений порядок измерений другой.
15. ivanov660 4980 22.07.22 08:45 Сейчас в теме
(13)Главный критерий - это наличие всех полей использующихся в соединениях.
14. TMV 1 21.07.22 23:12 Сейчас в теме
Остался только блок сканирования таблицы, чтобы избавиться от этого запроса нам надо попробовать переписать запрос срез последних, но этого уже мы делать не будем
Насколько помню, эта тема очень спорная - вам удалось переписать срез последних, вообще на практике используете?
16. ivanov660 4980 22.07.22 09:10 Сейчас в теме
(14)А почему спорная? В других системах учета нет никаких виртуальных таблиц и все делается руками. На сколько я помню коллеги говорили, что использование виртуальных таблиц упрощает сам запрос и позволяет не забыть включить служебные поля типа "Активность".
Сам запрос виртуальной таблицы можно переписать, к примеру так:
ВЫБРАТЬ
	Т.Номенклатура КАК Номенклатура,
	Т.ВидЦены КАК ВидЦены,
	Т.Характеристика КАК Характеристика,
	Т.Цена КАК Цена,
	Т.Упаковка КАК Упаковка
ИЗ
	(ВЫБРАТЬ
		МАКСИМУМ(Ц.Период) КАК Период,
		Ц.Номенклатура КАК Номенклатура,
		Ц.Характеристика КАК Характеристика,
		Ц.ВидЦены КАК ВидЦены
	ИЗ
		РегистрСведений.ЦеныНоменклатуры КАК Ц
	ГДЕ
		Ц.Активность = ИСТИНА
		И Ц.Период < &Период
	
	СГРУППИРОВАТЬ ПО
		Ц.Номенклатура,
		Ц.Характеристика,
		Ц.ВидЦены) КАК ВнТ
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.ЦеныНоменклатуры КАК Т
		ПО (Т.Номенклатура = ВнТ.Номенклатура)
			И (Т.Характеристика = ВнТ.Характеристика)
			И (Т.ВидЦены = ВнТ.ВидЦены)
			И (Т.Период = ВнТ.Период)
ГДЕ
	Т.Активность = ИСТИНА
Показать

Если это будет более оптимальный вариант, то почему же не использовать? Да, иногда мы вместо виртуальных таблиц мы используем работу с физическими таблицами.
Для отправки сообщения требуется регистрация/авторизация