Каталог решений - Исправляем проблемы производительности в конфигурации ERP — 7 примеров

Продолжаем набор статей по вопросам проблем производительности. Это следующая часть разборов ситуаций после перевода большой базы ERP на Postgres. Помните мы писали в предыдущей статье "нагрузочное тестирования в 5000+ онлайн" что вы будьте заниматься вопросами оптимизации? Это то что мы делали и Вам предстоит, если соберетесь выполнять подобную процедуру.

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

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

Вступление
1. Проблема быстродействия АРМ "Управление поступлением".
2. Опять 25. Получаем данные через две точки.
3. Плохой план Postgre SQL.
4. JIT оптимизация — это такая оптимизация!
5. Через две точки + плохие поля выбора и ужасные СКД отборы по ним.
6. Бесполезный индекс скан и отключенные итоги.
7. Нет отборов внутри виртуальных таблиц. Как так получилось?
Выводы

Вступление

О чем мы хотим рассказать?

Мы расскажем и покажем последовательность действий по выявлению проблемных мест производительности, а также реализацию исправлений на актуальных конфигурациях ERP/УТ/КА. Рассмотрим некоторые отличия в поведении MS SQL Server и PostgreSQL. Увидим, что если писать код в соответствии с рекомендациями, то система сможет относительно хорошо работать в любой СУБД.

Где-то мы будем более подробно рассказывать, где-то чуть более сжато. Но от этого ценность этого поста не снижается. Очень подробно про расследование проблемы производительности мы писали ранее в статье "Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками", попробуйте ознакомиться с ней прежде.

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

Краткое техническое вступление

Прежде чем вы начнете работать над вопросами мониторинга производительности, вам необходимо будет определиться с инструментами. Существует не так много инструментов, а хороших и удобных инструментов совсем мало. В нашем случае мы будем использовать конфигурацию (про которую я уже писал)  "Мониторинг производительности" с широким набором плагинов. Нам понадобятся следующие плагины и функционал:

• Парсер технологического журнала (встроен в конфигурацию);
• Парсер метрик производительности performance monitor для windows (встроен в конфигурацию);
• Классификатор ошибок технологического журнала;
• Обработка получения данных RAS 1C (с возможностью получения данных через com соединение).
• И др.

На что смотрим и ищем в журнале мониторинга (кратко):

• Долгие запросы, те, которые сильно отклоняются от общей картины в 2,3 и больше раз. Если у вас в среднем 10 с, то запросы 20,30, 60, 200, 1000 с точки оптимизации. Находим наиболее критичные и начинаем с них.
• Частые запросы середнячки и трудяги. Те, которых очень много. Отбираем и смотрим, можно ли их оптимизировать.
• Запросы с большим количеством возвращаемых данных. Отчеты, которые возвращают десятки тысяч строк.  Если на выходе пакета 10-15 записей, а промежуточные данные миллионы, то, возможно, не хватает фильтров.

На что смотрим в планах:

• Сканы таблиц, вместо них должны скорее всего быть индексы.
• Большие потоки данных, а на выходе 1-2 строки.
• Плохие отборы/фильтры.
• Множественные связи.
• Большое количество источников данных. 

Что смотрим в запросах:

• Большой текст,
• Большое количество таблиц (тоже может быть через две точки от поля составного типа),
• Длинные строки содержащие CASE … THEN CASE …. (это оператор через две точки от поля составного типа)
• Операторы LIKE,  ORDER по каким полям, большое количество полей у GROUP
• Большое количество данных.

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

Как улучшить понятность планов запросов в Postgres и MS SQL?

Для этого воспользуйтесь обработкой «Конвертация SQL в 1С». Она ищет таблицы и реквизиты, преобразует их в значения конфигурации. Запускать обработку необходимо в исследуемой конфигурации. Является частью Фреймворка «Мониторинг производительности».

Начинаем…5.4.3.2.1… поехали

1. Проблема быстродействия АРМ «Управление поступлением»

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

На решение проблемы отводилось довольно ограниченное время — пару часов. Получив фамилии пользователей мы погрузились в решение проблемы. Обратите внимание, что длительность в микро секундах, а если отбросить 6 нулей, то получим секунды. Время отработки запроса динамического списка на рисунке ниже от 100 до 4 000 с.

Теперь сделаем фильтр по одному пользователю:

Мы видим, что что-то произошло с 13 на 14 число. Первым делом посмотрим тексты запросов и сравним их. Это поле SQL для двух замеров до и после. В результате сравнения мы определили, что они одинаковые, т.е. это один и тот же запрос. Поэтому работаем дальше и пытаемся понять, что тут не так.

Определяем и смотрим позицию возникновения проблемы по Context.

Открываем и видим, что на форме находится несколько динамических списков. Для того, чтобы понять, что это за список, возьмем текст запроса SQL и преобразуем его с помощью конвертора SQL в 1С.

Обращаем внимание на относительно большое количество таблиц и наличие нескольких операторов "ВЫБОР" в поле "Комментарий" (выделено красной рамкой). Это выглядит как получение данных через две точки. Странно! Давайте смотреть дальше.

По тексту мы видим основную таблицу — "ЖурналДокументов.СкладскиеОрдера". Это второй динамический список, который расположен внизу формы. 

Открываем форму и смотрим свойство поля "Комментарий" формы.

Тут мы с вами видим, что путь к данным ведет не к ожидаемому реквизиту «Комментарий» журнала «СкладскиеОрдера», а к реквизиту «Ссылка.Комментарий» — обращение через две точки. Вот такая мина подложена в одном из самых востребованных АРМ конфигурации. В итоге вместо как минимум одной RLS  по журналу, будут добавляться платформой 1С еще три ограничения по всем ордерам. А может и больше, зависит от того, как группы доступа настроены администратором базы данных. 

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

Итоги: Мы обнаружили и исправили одну грубейшую ошибку рабочего места «Управление поступлением», приводящую к непозволительным и чудовищным падениям производительности в некоторых случаях. Пользователи довольны, а мы продолжили далее расследовать причину резкого снижения производительности в рамках зависимостей данных и RLS.

P.S. Данная ошибка на момент решения проблемы не исправлена в типовых конфигурациях ERP/КА/УТ. 

2. Опять 25. Получаем данные через две точки.

Решили посмотреть почему такое большое количество маленьких запросов 6-12 секунд. К тому же при выполнении анализа на глаза попался кластер содержащий вхождения слов «файл», «управление доступом» — мы воспользовались функционалом обработки из статьи "Автоматическая классификация технологического журнала" (подобный подход также применим к контекстам запросов, т.е. можем получить суждение, к какому кластеру относится подобный длительный запрос). 

Ого. Достаточно много позиций. Иногда достигает 10-15 позиций в минуту при самом пике нагрузки. Давайте посмотрим на частоту появления данной проблемы по всей базе данных, сгруппированную по дням:

Как мы видим, это довольно частая операция. Из графика видно, что до 16 часов суммарно процессор на сервере занимается непонятно чем — фактически минус одно ядро!

Позиция выполнения запроса. Что же тут не так? Давайте глянем текст запроса в SQL. Он очень большой.

Код совсем небольшой, и в нем нет такой кучи таблиц! Но зато есть выбор через две точки. Который и выдает нам соединения. В запросе мы находим в самом низу таблицу со следующим индексом «T258». 258 соединений. Вот зачем так делать?

Решение:

Файл измерение составного типа. В первой части выбора используем выразить, а во второй воспользуемся регистром сведений «Сведения о файлах».

В результате время с 13 с на тесте снизилось до 1 мс. Отличное решение!

Итоги оптимизации: Мы фактически устранили ошибку в типовой конфигурации, которая при достаточно больших объемах базы данных приводила к неоптимальной работы системы на обоих базах СУБД. 

3. Плохой план PostgreSQL

Смотрим дальше и находим следующую операцию, которая небольшая, но вызывает проблемы 6-12 с в зависимости от пользователя:

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

Давайте посмотрим контекст:

Как мы видим, общий модуль управления доступом и функция «Установить параметры сеанса». Идем в конфигурацию и ищем позицию в исходном коде.

Запрос представлен пакетом, нам нужен первая часть: