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

Публикация № 1611545 23.05.22

Администрирование БД - HighLoad оптимизация

Злободневные примеры поиска и исправления проблемных мест в конфигурациях ERP/УТ/КА на СУБД Postgres.

Продолжаем набор статей по вопросам проблем производительности. Это следующая часть разборов ситуаций после перевода большой базы 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 с в зависимости от пользователя:

 

 

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

 

 

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

 

 

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

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

 
 Код запроса

 

ВЫБРАТЬ РАЗЛИЧНЫЕ
	ЗначенияПоУмолчанию.ТипЗначенийДоступа КАК ТипЗначений,
	ЗначенияПоУмолчанию.ВсеРазрешеныБезИсключений КАК ВсеРазрешеныБезИсключений
ПОМЕСТИТЬ ЗначенияПоУмолчаниюДляПользователя
ИЗ
	РегистрСведений.ЗначенияГруппДоступаПоУмолчанию КАК ЗначенияПоУмолчанию
ГДЕ
	ИСТИНА В
			(ВЫБРАТЬ ПЕРВЫЕ 1
				ИСТИНА
			ИЗ
				Справочник.ГруппыДоступа.Пользователи КАК ГруппыДоступаПользователи
					ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.СоставыГруппПользователей КАК СоставыГруппПользователей
					ПО
						ГруппыДоступаПользователи.Ссылка = ЗначенияПоУмолчанию.ГруппаДоступа
							И ГруппыДоступаПользователи.Пользователь = СоставыГруппПользователей.ГруппаПользователей
							И СоставыГруппПользователей.Пользователь = &ТекущийПользователь)
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ РАЗЛИЧНЫЕ
	ЗначенияПоУмолчанию.ТипЗначений КАК ТипЗначений
ИЗ
	ЗначенияПоУмолчаниюДляПользователя КАК ЗначенияПоУмолчанию

СГРУППИРОВАТЬ ПО
	ЗначенияПоУмолчанию.ТипЗначений

ИМЕЮЩИЕ
	МИНИМУМ(ЗначенияПоУмолчанию.ВсеРазрешеныБезИсключений) = ИСТИНА

 

Как вы помните, проблемный кусок начинался с оператора «Insert», значит проблему вызывает первая часть. Запрос очень похож на использующиеся в RLS системы БСП.

Он не выглядит сложным, давайте взглянем на план запроса:

https://explain.tensor.ru/archive/explain/533c226e2a0008b2641ac0eb8ba205a2:0:2022-02-03#explain

 

 

Как мы видим самый тяжелый блок — начальный. Используется оператор соединения циклом, выполняется сканирование более 3 млн раз (циферки на верху кружка).

 

 

Давайте посмотрим как выглядит тот же план в базе СУБД MS SQL

 

 

Планы довольно похожи, за исключением времени выполнения (около 10 мс) и количества считанных и обработанных данных.

Теперь выполним рефакторинг-оптимизацию. Вынесем соединение из оператора «В» в соединение таблиц следующим образом:

 
 Оптимизированный запрос

 

ВЫБРАТЬ РАЗЛИЧНЫЕ
	ЗначенияПоУмолчанию.ТипЗначенийДоступа КАК ТипЗначений,
	ЗначенияПоУмолчанию.ВсеРазрешеныБезИсключений КАК ВсеРазрешеныБезИсключений
ПОМЕСТИТЬ ЗначенияПоУмолчаниюДляПользователя
ИЗ
	РегистрСведений.ЗначенияГруппДоступаПоУмолчанию КАК ЗначенияПоУмолчанию
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.ГруппыДоступа.Пользователи КАК ГруппыДоступаПользователи
		ПО (ГруппыДоступаПользователи.Ссылка = ЗначенияПоУмолчанию.ГруппаДоступа)
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.СоставыГруппПользователей КАК СоставыГруппПользователей
		ПО (ГруппыДоступаПользователи.Пользователь = СоставыГруппПользователей.ГруппаПользователей)
			И (СоставыГруппПользователей.Пользователь = &ТекущийПользователь)

 

Запрос выполняется в консоли запросов менее чем за 10 мс. Время работы стало приемлемо. Посмотрим план выполнения:

https://explain.tensor.ru/archive/explain/947e585afc8fd23b64a7f9331d406320:0:2022-02-03#explain

 

 

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

Получим план исправленного запроса в базе MS SQL. Он практически не изменился. По времени выполнения и количеству считываемых и обрабатываемых записей остался на том же уровне.

 

 

Итоги оптимизации: Успех! Мы фактически вернули быстродействие процедуры в целевые незначительные по времени рамки, избавив пользователей от проблемы ожидания лишних 5-12 с при запуске внешних обработок и отчетов. Быстродействие увеличилось в 5000 раз. Фактически мы выполнили оптимизацию под требования базы постгре, но также поведение базы MS SQL не изменилось. Данная процедура рефакторинга может быть применена в изначальной конфигурации вендора 1С для конфигураций ERP/УТ/КА.

P.S. Проверили на Postgres 13, тот же запрос выполняется гораздо лучше 500 мс (в 20 раз лучше),  план более правильный, но все равно немного хуже оптимизированного:

https://explain.tensor.ru/archive/explain/613554aae7064b7e3d010e3b34f68d00:0:2022-04-01#visio

 

 

4. JIT оптимизация — это такая оптимизация!

 

В данном примере речь пойдет об оптимизаторе Postgres. Мне давно эти всякие штучки-дрючки казались подозрительными, но все времени не было детально посмотреть. Ситуация проявилась после обновления платформы. Этот шаг был необходим в связи с ситуацией рассмотренной в примере «Пример расследования проблемы производительности по шагам с картинками». Согласно рекомендациям мы обновили платформу у заказчика и со спокойной совестью отправились спать, чтобы утром прикинуть, насколько эффективно работает новая платформа, но… Утро не было таким радостным, а скорее облило словно холодный душ, а к вечеру ситуация стала довольно очевидна — это выглядело как провал, а не успех. На рисунке красным показана дата обновления платформы с 8.3.16 на 8.3.19. Мы видим резкий рост проблемных запросов.

Контрмеры были предприняты — показано синим цветом.

 

 

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

 

 

Начали смотреть по пользователям. Сложилась следующая картинка, время выполнения по пользователям не изменилось и осталось средним, но появилось много новых пользователей с временем более 5 с. Знаете почему такое критичное количество? Ответ довольно прост — форма мои задачи обычно находится на начальной странице и стоит авто обновление раз в минуту. Отключать авто обновление нельзя, т.к. новые задачи должны появляться без принудительного обновления списка пользователем. Удобно было бы, если бы появлялось уведомление о новых задачах, но, думаю, это будет в следующих релизах.

План запроса

https://explain.tensor.ru/archive/explain/50e1baada886a76571761e2d06468b05:0:2022-03-06#visio

 

 

Удивила выделенная операция — оператор «Limit», которая занимает до 93.3%. Это довольно непонятное состояние. Общее время получилось в районе 25 с.

 

 

Обратите внимание, сколько времени занимает выполнение оптимизации оператором JIT.

Для того чтобы оценить, какую выгоду вносит сам jit, нам необходимо выполнить запрос с отключенным оптимизатором.

 

 

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

https://explain.tensor.ru/archive/explain/85975ea000377da98ffea641e1672d88:0:2022-03-07#visio

Общее время снизилось до 1,5 с. В данном случае использование оптимизатора значительно ухудшает время выполнения запроса. Почему так происходит? Не верно предсказывается сложность выполнения запроса. Думаю, что большой вклад в ошибку вносит наличие сложной RLS, накладываемой на таблицу платформой 1С. Выполнение обновления статистики в данном случае не помогает. 

Решение:

Для дальнейших действий можно выделить несколько вариантов:

  • отключить в настройках конфигурации JIT = off. Полностью отключаем.
  • увеличить параметры срабатывания  jit_optimize_above_cost, по умолчанию стоит 500 000.
  • отключить использование оптимизатора  jit_optimize_above_cost=-1.

Первоначально было принято решение увеличить порог срабатывания до  значения 1 500 000. Эффект получился практически мгновенным - более 70% запросов ушло. В таблице данное событие отражает пятница.

Хочу отметить тот факт, что сами разработчики постгрез и jit отмечают следующее:  включать этот механизм для всех ситуаций не стоит, настраивайте под свою систему.

Но все равно остались некоторые запросы и был выполнен следующий шаг:  jit_optimize_above_cost=-1.
Показатель рабочая суббота. Как видно из рисунка, снизилось не только количество событий, но и среднее время выполнения. Фактически исчезло большое добавочное время работы JIT.

https://explain.tensor.ru/archive/explain/9f366440c300acdd2ad6a83185761eaf:0:2022-03-07#visio

 

 

Время сократилось до 4 с. Но оптимизатор продолжает вносить лишнюю задержку.

 

 

Смотрим далее. Количество проблемных запросов уменьшилось, но не исчезло совсем. 

 

 

Проблема, которая осталась — это время на обработку RLS. Из картинки видно, что акцент на операторе сканирования таблицы «Группы доступа». 

https://explain.tensor.ru/archive/explain/a41092a7a08caad8a7d7afc4393fab30:0:2022-03-07#visio

 

 

Решение данного вопроса может состоять в двух следующих частях:

  • анализ текущих настроек прав доступа и удаление излишних
  • использование другой модели RLS, к этому варианту мы вернемся в следующих статьях.

 

5. Через две точки + плохие поля выбора и ужасные СКД отборы по ним

 

Открыли список и поставили отбор на 1000 с. И немножко ужаснулись тому, что увидели. Но самое странное — это запросы длительностью в 20 000 -34 000 с.

 

 

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

 

 

Тут мы столкнулись с проблемой медленного открытия формы динамического списка в базе при подборе товаров в коммерческое предложение. Давайте посмотрим, что там такое, судя по всему ничего хорошего!

 

 

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

 
 Изначальный запрос

 

Через пару минут, может кто-то быстрее, мы замечаем довольно очевидную и грубую ошибку - получение данных через две точки от составного типа.

 

 

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

Решение: Будем избавляться от получения данных через точку. Для этого воспользуемся реестром документов.

Ниже приведен оптимизированный запрос:

 
 Запрос оптимизированный, первая итерация

 

Выполняем запрос и смотрим его план:

https://explain.tensor.ru/archive/explain/bfb5890f29681376b39e60668b20b169:0:2022-03-29#visio

 

\

 

Вроде все здорово. Вносим код в конфигурацию. Но на форме есть флажок фильтра "Только заказы по организации ...", и если мы его активируем, то быстродействие у нас опять приземляется. Не так сильно, но 60 с тоже много. Что за дела? Должно же быть еще быстрее, мы же добавили фильтр?

Смотрим план запроса для этой ситуации:

https://explain.tensor.ru/archive/explain/f1a39936379c9917f0f27972b3df5c5d:0:2022-03-29#visio

 

 

На рисунке ниже мы видим операцию сканирования, которая выполняется 1,3 млн раз (жирный красный кружок на рисунке выше и цифра в красном овале). В данном случае происходит перебор всех ссылок таблицы назначений, а их очень много. Давайте попробуем понять, из-за чего такое происходит. 

Возьмем тексты запросов первого и второго случая, и их сравним. В результате увидим отличие в секции «ГДЕ» - вылезает наш отбор по организации. Но выглядит он странно, ужасно и непонятно, что это и как такое получилось? 

 


Объясняем. Поле «Организация» у нас находится в выбранных на вывод полях.

 

 

Далее в коде есть функция, которая добавляет по нему отбор СКД. А СКД накладывает отбор, взяв представление вывода поля и добавив его в условие примерно так:

 

 

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

Зачем так сделано? Видимо, этот код пришел из глубокой древности, когда ничего про оформление динамических списков разработчику не было известно и такой возможности не было, возможно, с обычных форм. Цель - для того случая, когда отсутствует заказ, чтобы вместо демонстрации пустой ссылки выводился текст «не используется».

Убираем эту конструкцию для поля организация и переписываем запрос еще раз:

 
 Еще одна итерация оптимизации

 

Наконец! Наш запрос начал летать:

https://explain.tensor.ru/archive/explain/1c2ce18da2cf7dc94e08fbe5bc0ecf45:0:2022-03-29#visio

 

 

Резюме: время выполнения мы снизили на просто космическую разницу с 34 000 с до 100 мс, это ускорение более чем в 340 000 раз. И запомните, что используем везде условное оформление для динамических списков, а всю ересь и подобные выкрутасы выше надо запрещать и бить по рукам!

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

 

6. Бесполезный индекс скан и отключенные итоги

 

Продолжаем смотреть, что  у нас еще "плохого" в базе данных. Ставим отбор в 300 сек и немного «ужасаемся» от такого количества проблемных ситуаций. Мы видим — ультра долгие запросы. Среди очень больших времен выполнения запросов в глаза сразу бросается проблема с пиком в 1400 секунд (это чуть больше 23 минут). Можно уже мысленно провести параллель с «эстонской» оперативной базой учета.

 

 

Посмотрим где это встречается.

 

 

Давайте посмотрим картинку с отбором по вхождению в контекст условия «РабочееМестоМенеджераПоДоставке». Что тут у нас единичный или закономерность?

 

 

Как мы видим, то прослеживается закономерность. И подсказка нам сообщает, что это все происходит в динамических списках.

Запрос SQL очень большой и понять из него сходу что-то очень сложно, поэтому мы будем смотреть план запроса. Открываем файл лога базы и ищем по времени план соответствующего запроса.

Посмотрим план запроса, конечно, предварительно его преобразуем через конвертер SQL в 1С.

https://explain.tensor.ru/archive/explain/d676eebfb35e11e0379ae298b7d7607c:0:2022-01-22#visio

 

 

Как мы видим (два жирных красных кружка на рисунке выше), все основные ресурсы сжирает процедура Index Only Scan и группировка. Давайте глянем, что там такое. Суммарное время 1369 с (728 с + 641 с). Еще 111 с расходуются на соединение, идущее следом.

 

 

Наш Index Only Scan на самом деле выполняет лишнюю и ненужную работу, т.к. условие поиска по индексу «Index Cond» - «Область данных основные данные»=0 - фактически все записи таблицы - это бесполезные итоги! Много говорили про область данных и еще много скажут, но, на мой взгляд, это один из самых коварных элементов любой конфигурации БСП. По факту  результат работы этого оператора похож на последовательное чтение (Seq Scan), но только по таблице индекса. Слишком много данных читается, чтобы потом пользователю вывести 45 записей.

Открываем целевую конфигурацию, открываем форму «РабочееМестоМенеджераПоДоставке» и ищем запрос. Смотрим и ….


 

 
 Проблемный запрос

 

Как видим, то запрос выглядит совсем ужасно. Но давайте взглянем на SQL код postgres, чтобы понять, что там еще есть такое. Он нам понадобится для дальнейшего анализа проблем.

 
 SQL представление проблемного запроса

 

И наш блок — это вот такой код:

 

 

Система выполняет создание таблицы срез последних прямо в коде. Зачем она так делает?

Давайте проверим настройки этого регистра сведений. Открываем в конфигурации этот регистр сведений, переходим на вкладку прочее и смотрим позиции "Разрешить итоги".

 

 

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

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

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

https://explain.tensor.ru/archive/explain/bc39a18fd4de4601576b122332ffb35b:0:2022-01-22#visio

 

 

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

 

 

Тут уже сканирование таблицы точек погрузки и разгрузки. Давайте поищем в запросе таблицу с именем «T41».

 

 

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

 

7. Нет отборов внутри виртуальных таблиц. Как так получилось?

 

Анализируем журнал длительных запросов и замечаем еще один запрос длительностью более 1000 секунд. 

 

 

Контекст запроса выглядит следующим образом:

 

 

Давайте посмотрим, насколько часто встречается этот запрос. Для этого в фильтр списка добавим словосочетание из контекста. К примеру, вот так "ТоварыРазмещение.Загрузить(Запрос.Выполнить().Выгрузить())".

 

 

Событий достаточно много. Давайте откроем конфигурацию и посмотрим что там такое. Вспоминаем описание контекста и открываем модуль объекта документа "Отбор и размещение товаров". Далее жмем "Ctrl+G" и переходим к 581 строке. Следующим этапом находим запрос, который чуть выше.

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

 

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

 

ВЫБРАТЬ
	ТоварыВЯчейкахОбороты.Номенклатура КАК Номенклатура,
	ТоварыВЯчейкахОбороты.Характеристика КАК Характеристика,
	ТоварыВЯчейкахОбороты.Назначение КАК Назначение,
	ТоварыВЯчейкахОбороты.Упаковка КАК Упаковка,
	ТоварыВЯчейкахОбороты.Ячейка КАК Ячейка,
	ТоварыВЯчейкахОбороты.Серия КАК Серия,
	СУММА(ТоварыВЯчейкахОбороты.ВНаличииОборот) КАК ВНаличииОборот
ПОМЕСТИТЬ вт_КорректировкиНазначений
ИЗ
	РегистрНакопления.ТоварыВЯчейках.Обороты(,,Авто,) КАК ТоварыВЯчейкахОбороты
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ вт_ДвиженияПоНазначению КАК вт_ДвиженияПоНазначению
		ПО ТоварыВЯчейкахОбороты.Номенклатура = вт_ДвиженияПоНазначению.Номенклатура
			И ТоварыВЯчейкахОбороты.Характеристика = вт_ДвиженияПоНазначению.Характеристика
			И ТоварыВЯчейкахОбороты.Ячейка = вт_ДвиженияПоНазначению.Ячейка
			И ТоварыВЯчейкахОбороты.Серия = вт_ДвиженияПоНазначению.Серия
			И ТоварыВЯчейкахОбороты.Упаковка = вт_ДвиженияПоНазначению.Упаковка
			И ТоварыВЯчейкахОбороты.Регистратор = вт_ДвиженияПоНазначению.Регистратор

СГРУППИРОВАТЬ ПО
	ТоварыВЯчейкахОбороты.Номенклатура,
	ТоварыВЯчейкахОбороты.Характеристика,
	ТоварыВЯчейкахОбороты.Назначение,
	ТоварыВЯчейкахОбороты.Упаковка,
	ТоварыВЯчейкахОбороты.Ячейка,
	ТоварыВЯчейкахОбороты.Серия

 

 

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

https://explain.tensor.ru/archive/explain/1e16f485e815a9b4fcab27daf6e4db9e:0:2022-03-05#visio

 

 

Давайте рассмотрим, что тут происходит и в какой последовательности. 

  1. Первым делом выбираются записи из физической таблицы "Товары в ячейках". Обратите внимание на стрелку "товары в ячейках".
  2. Далее на каждую строку таблицы выше накладывается ограничение RLS. Позиция от левого края рисунка до стрелки "RLS фильтр".
  3. Следующим шагом происходит агрегация. Стрелочка "обороты".
  4. И в конечном шаге накладывается фильтр/отбор по тем позициям, которые нужны. Это позиция со стрелочкой "фильтр по нужным товарным позициям 'временная таблица'"

Согласитесь, агрегировать все записи (около 300 тыс.), чтобы потом взять 10-20 штук, это немного перебор? Вспоминаем рекомендации, которые написаны в желтой книжке: "Отборы делать необходимо внутри виртуальных таблиц".

Но почему же такую ошибку никто не заметил ранее? Все дело в том, что MS SQL выполняет данный запрос более умно и поднимает автоматически фильтр на уровень выше. Как мы увидим дальше, то план исходного запроса MS SQL похож на план оптимизированного запроса Postgres. Давайте посмотрим на картинку, как выглядит план запроса там:

  1. Из таблицы индекса "Товары в ячейках" выбираются сразу необходимые записи. Отражено красным текстом - "поиск по индексу в ячейках";
  2. Этот фильтр из временной таблицы применяется через Nested Loop. Позиция по тексту "фильтр по набору данных";
  3. Далее фильтруется по ограничению RLS - "отбор по RLS";
  4. И наконец формируется виртуальная таблица обороты в районе оператора "Stream Aggregate" - "обороты".

 

 

Решение: Оптимизируем запрос в соответствии с рекомендациями - добавляем отбор внутрь виртуальной таблицы "Обороты". Итоговый запрос приведен ниже:

 
 Оптимизированный запрос

 

ВЫБРАТЬ
	ТоварыВЯчейкахОбороты.Номенклатура КАК Номенклатура,
	ТоварыВЯчейкахОбороты.Характеристика КАК Характеристика,
	ТоварыВЯчейкахОбороты.Назначение КАК Назначение,
	ТоварыВЯчейкахОбороты.Упаковка КАК Упаковка,
	ТоварыВЯчейкахОбороты.Ячейка КАК Ячейка,
	ТоварыВЯчейкахОбороты.Серия КАК Серия,
	СУММА(ТоварыВЯчейкахОбороты.ВНаличииОборот) КАК ВНаличииОборот
ПОМЕСТИТЬ вт_КорректировкиНазначений
ИЗ
	РегистрНакопления.ТоварыВЯчейках.Обороты(
			,
			,
			Авто,
			(Номенклатура, Характеристика, Ячейка, Серия, Упаковка) В
				(ВЫБРАТЬ
					вт_ДвиженияПоНазначению.Номенклатура,
					вт_ДвиженияПоНазначению.Характеристика,
					вт_ДвиженияПоНазначению.Ячейка,
					вт_ДвиженияПоНазначению.Серия,
					вт_ДвиженияПоНазначению.Упаковка
				ИЗ
					вт_ДвиженияПоНазначению)) КАК ТоварыВЯчейкахОбороты
		ВНУТРЕННЕЕ СОЕДИНЕНИЕ вт_ДвиженияПоНазначению КАК вт_ДвиженияПоНазначению
		ПО ТоварыВЯчейкахОбороты.Номенклатура = вт_ДвиженияПоНазначению.Номенклатура
			И ТоварыВЯчейкахОбороты.Характеристика = вт_ДвиженияПоНазначению.Характеристика
			И ТоварыВЯчейкахОбороты.Ячейка = вт_ДвиженияПоНазначению.Ячейка
			И ТоварыВЯчейкахОбороты.Серия = вт_ДвиженияПоНазначению.Серия
			И ТоварыВЯчейкахОбороты.Упаковка = вт_ДвиженияПоНазначению.Упаковка
			И ТоварыВЯчейкахОбороты.Регистратор = вт_ДвиженияПоНазначению.Регистратор

СГРУППИРОВАТЬ ПО
	ТоварыВЯчейкахОбороты.Номенклатура,
	ТоварыВЯчейкахОбороты.Характеристика,
	ТоварыВЯчейкахОбороты.Назначение,
	ТоварыВЯчейкахОбороты.Упаковка,
	ТоварыВЯчейкахОбороты.Ячейка,
	ТоварыВЯчейкахОбороты.Серия

 

 

Давайте посмотрим, что изменилось в плане, а изменилось многое:

https://explain.tensor.ru/archive/explain/3e0fa834b97e79002b47f3376ea812c2:0:2022-05-22#visio

 

 

Порядок операций изменился, и время выполнения сократилось до 145 мс. Порядок действий примерно можно описать так:

  1. Теперь отбираются необходимые записи из индекса таблицы "Товары в ячейках". На рисунке отмечено "индекс по таблице 'товары в ячейках'";
  2. Фильтр для пункта 1 используется из временной таблицы. Отмечено "фильтр по набору данных";
  3. Следующим шагом выполняется проверка RLS - это "RLS ограничения";
  4. Последним шагом выполняется агрегация этих десятков записей, на рисунке "обороты" .

Резюме: В результате наших мероприятий время выполнения снизилось почти в ~7 000 раз, мы перестали обрабатывать лишние данные и сразу стало быстро. Поэтому - Пишите запросы согласно рекомендациям и не полагайтесь на умный планировщик.

 

Послесловие:

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


Выводы:

 

  1. В текущих типовых конфигурациях достаточно проблемных мест, которые серьезно снижают производительность высоконагруженных продуктовых баз.
  2. При переходе на СУБД Postgres с MS SQL будьте готовы вложить ресурсы (время, деньги, разработчиков) на доведение работы системы до приемлемого уровня, особенно в критичных местах для бизнеса. Будьте готовы к тому, что потребуется оптимизация запросов под целевую СУБД и в некоторых случаях под версию СУБД.
  3. Если вы задумаетесь над переходом на другую СУБД, то необходимо выявить ключевые точки в системе и выполнить нагрузочное тестирование. Про проведения нами такого тестирования мы рассказали в статье "Нагрузочное тестирование 5000+ онлайн".
  4. Ошибки, которые встречаются в конфигурации, фактически одни и те же (мы рассматривали тут - Распространенные ошибки разработчиков, приводящие к проблемам производительности):
    • выбор полей через точку в составных типах;
    • неоптимальные отборы;
    • отсутствие индексов;
    • сложные многоуровневые запросы;
    • невнимательность;
    • использование подхода - да и так сойдет;
    • квалификация разработчиков;
    • отсутствие нормального нагрузочного тестирования на больших базах под различными сложными RLS;
    • встречающиеся ошибки платформы 1С;
    • и другие.
  5. Следование стандартам разработки позволит избежать большинства проблем. 
  6. Используйте подходящие инструменты мониторинга, держите руку на пульсе, чтобы по возможности заранее выявлять и устранять проблемные узкие места.

 

Специальные предложения

Вознаграждение за ответ
Показать полностью
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. sapervodichka 5789 23.05.22 14:38 Сейчас в теме
Спасибо, что делишься опытом!
m1_1976; Gavrik; Artem-B; akR00b; ivanov660; +5 Ответить
2. quazare 2265 23.05.22 15:02 Сейчас в теме
титанический труд
Gavrik; Yashazz; Drivingblind; ivanov660; pavlov_dv; +5 Ответить
3. CheBurator 3073 23.05.22 18:09 Сейчас в теме
"Недоделанные отчеты - это не беда. Главное - доделывайте детей. А то они вырастают и приносячт недоделанные отчеты. И никак не разорвать этот порочный круг"
Yashazz; sapervodichka; +2 Ответить
4. sapervodichka 5789 23.05.22 21:29 Сейчас в теме
(3)
Прикрепленные файлы:
m1_1976; user1286487; +2 Ответить
5. PerlAmutor 127 24.05.22 05:24 Сейчас в теме
Ну вроде бы не так много в 2.5.8 через двойную точку путей

Хотелось бы увидеть как можно оптимизировать текст запроса динамического списка формы Диспетчирование документа ЭтапПроизводства2_2:

ВЫБРАТЬ
	Этапы.Статус КАК Статус,
	&ПредставлениеЭтапа КАК ПредставлениеЭтапа,
	Этапы.Распоряжение КАК Распоряжение,
	Этапы.Распоряжение.Подразделение КАК ПодразделениеДиспетчер,
	Этапы.НаименованиеЭтапа КАК НаименованиеЭтапа,
	Этапы.ПроизводствоНаСтороне КАК ПроизводствоНаСтороне,
	Этапы.Подразделение КАК Подразделение,
	Этапы.Спецификация КАК Спецификация,
	Этапы.ПартияПроизводства КАК ПартияПроизводства,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
				И ИСТИНА В
					(ВЫБРАТЬ ПЕРВЫЕ 1
						ИСТИНА
					ИЗ
						РегистрСведений.ЗаданияКРасчетуГрафикаПроизводства КАК Т
					ГДЕ
						Т.Распоряжение = Этапы.Распоряжение
						И Т.ЭтапПроизводства = Этапы.Ссылка)
			ТОГДА ИСТИНА
		ИНАЧЕ ЛОЖЬ
	КОНЕЦ КАК ТребуетсяПланироватьГрафик,
	ЕСТЬNULL(СостоянияЭтаповПроизводства.ТребуетОбеспечения, ЛОЖЬ) КАК ТребуетсяОбеспечение,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
			ТОГДА ВЫБОР
					КОГДА ЕСТЬNULL(ГрафикПроизводства.ОграничиваетСрокВыпуска, ЛОЖЬ) = ИСТИНА
						ТОГДА 3
					КОГДА ЕСТЬNULL(ГрафикПроизводства.НаКритическомПути, ЛОЖЬ) = ИСТИНА
						ТОГДА 2
					ИНАЧЕ -1
				КОНЕЦ
		ИНАЧЕ -1
	КОНЕЦ КАК СостояниеОграниченийВГрафике,
	ЕСТЬNULL(СостоянияЭтаповПроизводства.СостояниеНаМежцеховомУровне, &ПустаяСсылкаСостояние) КАК СостояниеЭтапа,
	ЕСТЬNULL(СостоянияЭтаповПроизводства.СостояниеОпераций, &ПустаяСсылкаСостояниеОпераций) КАК СостояниеОпераций,
	ВЫБОР
		КОГДА Этапы.ТребуетсяЗаполнитьПоОперациям
			ТОГДА 3
		КОГДА СостоянияЭтаповПроизводства.СостояниеОпераций = ЗНАЧЕНИЕ(Перечисление.СостоянияОперацийЭтапаПроизводства.ОжидаетНазначения)
			ТОГДА 0
		КОГДА СостоянияЭтаповПроизводства.СостояниеОпераций = ЗНАЧЕНИЕ(Перечисление.СостоянияОперацийЭтапаПроизводства.ОжидаетЗавершения)
			ТОГДА 1
		КОГДА СостоянияЭтаповПроизводства.СостояниеОпераций = ЗНАЧЕНИЕ(Перечисление.СостоянияОперацийЭтапаПроизводства.Выполнено)
			ТОГДА 2
		ИНАЧЕ -1
	КОНЕЦ КАК КодСостоянияОпераций,
	Этапы.ТребуетсяЗаполнитьПоОперациям КАК ТребуетсяЗаполнитьПоОперациям,
	НЕ Этапы.ТребуетсяЗаполнитьПоОперациям
		И СостоянияЭтаповПроизводства.СостояниеОпераций = ЗНАЧЕНИЕ(Перечисление.СостоянияОперацийЭтапаПроизводства.ОжидаетНазначения) КАК ТребуетсяНазначитьОперации,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
			ТОГДА НЕ ГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
		ИНАЧЕ НЕ НормативныйГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
	КОНЕЦ КАК ГрафикРассчитан,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
				И НЕ ГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
			ТОГДА НАЧАЛОПЕРИОДА(ГрафикПроизводства.НачалоЭтапа, ДЕНЬ)
		ИНАЧЕ НАЧАЛОПЕРИОДА(ДОБАВИТЬКДАТЕ(Этапы.Распоряжение.НачатьНеРанее, СЕКУНДА, ЕСТЬNULL(НормативныйГрафикПроизводства.ДлительностьДоЗапуска, 0)), ДЕНЬ)
	КОНЕЦ КАК ДатаСобытия,
	ВЫБОР
		КОГДА &ДатаАктуальности > ВЫБОР
					КОГДА &ПланируетсяГрафикПроизводства
							И НЕ ГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
						ТОГДА ГрафикПроизводства.НачалоЭтапа
					ИНАЧЕ ДОБАВИТЬКДАТЕ(Этапы.Распоряжение.НачатьНеРанее, СЕКУНДА, ЕСТЬNULL(НормативныйГрафикПроизводства.ДлительностьДоЗапуска, 0))
				КОНЕЦ
				И Этапы.Статус В (&СтатусФормируется, &СтатусСформирован, &СтатусКВыполнению)
			ТОГДА ИСТИНА
		ИНАЧЕ ЛОЖЬ
	КОНЕЦ КАК Просрочен,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
				И НЕ ГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
			ТОГДА ГрафикПроизводства.НачалоЭтапа
		ИНАЧЕ ДОБАВИТЬКДАТЕ(Этапы.Распоряжение.НачатьНеРанее, СЕКУНДА, ЕСТЬNULL(НормативныйГрафикПроизводства.ДлительностьДоЗапуска, 0))
	КОНЕЦ КАК ДатаНачала,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
				И НЕ ГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
			ТОГДА ГрафикПроизводства.ОкончаниеЭтапа
		ИНАЧЕ ДОБАВИТЬКДАТЕ(Этапы.Распоряжение.НачатьНеРанее, СЕКУНДА, ЕСТЬNULL(НормативныйГрафикПроизводства.ДлительностьДоЗапуска + НормативныйГрафикПроизводства.Ресурсоемкость, 0))
	КОНЕЦ КАК ДатаЗавершения,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
				И НЕ ГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
			ТОГДА ВЫБОР
					КОГДА Этапы.Статус В (&СтатусФормируется, &СтатусСформирован, &СтатусКВыполнению)
							И РАЗНОСТЬДАТ(ГрафикПроизводства.НачалоЭтапа, &ДатаАктуальности, ДЕНЬ) > 0
						ТОГДА РАЗНОСТЬДАТ(ГрафикПроизводства.НачалоЭтапа, &ДатаАктуальности, ДЕНЬ)
					КОГДА Этапы.Статус = &СтатусНачат
							И РАЗНОСТЬДАТ(ГрафикПроизводства.ОкончаниеЭтапа, &ДатаАктуальности, ДЕНЬ) > 0
						ТОГДА РАЗНОСТЬДАТ(ГрафикПроизводства.ОкончаниеЭтапа, &ДатаАктуальности, ДЕНЬ)
					КОГДА Этапы.Статус = &СтатусЗавершен
							И РАЗНОСТЬДАТ(ГрафикПроизводства.ОкончаниеЭтапа, Этапы.ФактическоеОкончаниеЭтапа, ДЕНЬ) > 0
						ТОГДА РАЗНОСТЬДАТ(ГрафикПроизводства.ОкончаниеЭтапа, Этапы.ФактическоеОкончаниеЭтапа, ДЕНЬ)
					ИНАЧЕ 0
				КОНЕЦ
		ИНАЧЕ 0
	КОНЕЦ КАК Задержка,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
			ТОГДА ВЫБОР
					КОГДА НЕ ГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
							И (&ДатаАктуальности > ГрафикПроизводства.НачалоЭтапа
									И Этапы.Статус В (&СтатусФормируется, &СтатусСформирован, &СтатусКВыполнению)
								ИЛИ &ДатаАктуальности > ГрафикПроизводства.ОкончаниеЭтапа
									И Этапы.Статус <> &СтатусЗавершен)
						ТОГДА ИСТИНА
					ИНАЧЕ ЛОЖЬ
				КОНЕЦ
		ИНАЧЕ ВЫБОР
				КОГДА НЕ НормативныйГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
						И (&ДатаАктуальности > ДОБАВИТЬКДАТЕ(Этапы.Распоряжение.НачатьНеРанее, СЕКУНДА, ЕСТЬNULL(НормативныйГрафикПроизводства.ДлительностьДоЗапуска, 0))
								И Этапы.Статус В (&СтатусФормируется, &СтатусСформирован, &СтатусКВыполнению)
							ИЛИ &ДатаАктуальности > ДОБАВИТЬКДАТЕ(Этапы.Распоряжение.НачатьНеРанее, СЕКУНДА, ЕСТЬNULL(НормативныйГрафикПроизводства.ДлительностьДоЗапуска + НормативныйГрафикПроизводства.Ресурсоемкость, 0))
								И Этапы.Статус <> &СтатусЗавершен)
					ТОГДА ИСТИНА
				ИНАЧЕ ЛОЖЬ
			КОНЕЦ
	КОНЕЦ КАК ЕстьОтставаниеОтГрафика,
	ВЫБОР
		КОГДА Этапы.РучноеРазмещениеВГрафике
			ТОГДА 1
		КОГДА &ПланируетсяГрафикПроизводства
				И НЕ ГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
				И (ТИПЗНАЧЕНИЯ(Этапы.ПланироватьНеРанее) = ТИП(ДАТА)
						И Этапы.ПланироватьНеРанее <> ДАТАВРЕМЯ(1, 1, 1)
					ИЛИ ТИПЗНАЧЕНИЯ(Этапы.ПланироватьНеРанее) = ТИП(Документ.ЭтапПроизводства2_2)
						И Этапы.ПланироватьНеРанее <> ЗНАЧЕНИЕ(Документ.ЭтапПроизводства2_2.ПустаяСсылка))
			ТОГДА 0
		ИНАЧЕ -1
	КОНЕЦ КАК ДатаНачалаИндексКартинки,
	ВЫБОР
		КОГДА Этапы.РучноеРазмещениеВГрафике
			ТОГДА 1
		ИНАЧЕ -1
	КОНЕЦ КАК ДатаОкончанияИндексКартинки,
	Этапы.ЖелаемаяДатаОбеспечения КАК ЖелаемаяДатаОбеспечения,
	ВЫБОР
		КОГДА &ПланируетсяГрафикПроизводства
			ТОГДА ВЫБОР
					КОГДА Этапы.ЖелаемаяДатаОбеспечения <> ДАТАВРЕМЯ(1, 1, 1)
							И ЕСТЬNULL(ГрафикПроизводства.НачалоЭтапа, ДАТАВРЕМЯ(1, 1, 1)) <> ДАТАВРЕМЯ(1, 1, 1)
							И Этапы.ЖелаемаяДатаОбеспечения > ГрафикПроизводства.НачалоЭтапа
						ТОГДА ИСТИНА
					ИНАЧЕ ЛОЖЬ
				КОНЕЦ
		ИНАЧЕ ВЫБОР
				КОГДА Этапы.ЖелаемаяДатаОбеспечения <> ДАТАВРЕМЯ(1, 1, 1)
						И НЕ НормативныйГрафикПроизводства.ЭтапПроизводства ЕСТЬ NULL
						И Этапы.ЖелаемаяДатаОбеспечения > ДОБАВИТЬКДАТЕ(Этапы.Распоряжение.НачатьНеРанее, СЕКУНДА, ЕСТЬNULL(НормативныйГрафикПроизводства.ДлительностьДоЗапуска, 0))
					ТОГДА ИСТИНА
				ИНАЧЕ ЛОЖЬ
			КОНЕЦ
	КОНЕЦ КАК ЖелаемаяДатаОбеспеченияПросрочена,
	Этапы.Ссылка КАК Ссылка
ИЗ
	Документ.ЭтапПроизводства2_2 КАК Этапы
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.НормативныйГрафикЭтаповПроизводства КАК НормативныйГрафикПроизводства
		ПО Этапы.Ссылка = НормативныйГрафикПроизводства.ЭтапПроизводства
		ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.СостоянияЭтаповПроизводства КАК СостоянияЭтаповПроизводства
		ПО Этапы.Распоряжение = СостоянияЭтаповПроизводства.Распоряжение
			И Этапы.Ссылка = СостоянияЭтаповПроизводства.Этап
		{ЛЕВОЕ СОЕДИНЕНИЕ РегистрСведений.ГрафикЭтаповПроизводства2_2 КАК ГрафикПроизводства
		ПО Этапы.Распоряжение = ГрафикПроизводства.Распоряжение
			И Этапы.Ссылка = ГрафикПроизводства.ЭтапПроизводства
			И (ГрафикПроизводства.СтатусГрафика = &СтатусРабочийГрафик)}
ГДЕ
	НЕ Этапы.ПометкаУдаления
Показать


Суть проблемы. В динамическом списке есть настройка упорядочивания по полю "ДатаНачала". Но это поле вычисляемое, как следствие не индексируется. Если в БД огромное количество этапов (десятки миллионов), то со списком становится невозможно работать, т.к. любая прокрутка подвешивает пользователя не минуты. Хуже того, этот список имеет настройку автообновления, что приводит к тем же результатам.
Прикрепленные файлы:
sapervodichka; +1 Ответить
6. ivanov660 3545 24.05.22 08:35 Сейчас в теме
(5)
1. Проблема через две точки существенна только для составных типов.
2. Сортировка по расчетному полю не очень хорошо, но почему вы считаете что проблема в нем? Вы план запроса смотрели? Прикладывайте посмотрим дадим совет.
В базах бывают и миллиарды записей и вполне себе работает.
15. PerlAmutor 127 24.05.22 18:20 Сейчас в теме
(6)
2. Сортировка по расчетному полю не очень хорошо, но почему вы считаете что проблема в нем? Вы план запроса смотрели? Прикладывайте посмотрим дадим совет.

Этой проблеме уже не первый год, в 2019 году план запроса смотрел. Если немного разгружусь с работой, то выложу. У себя сделали просто - отключили настройку сортировки и запретили пользователям упорядочивать все поля в динамическом списке. После этого жалобы от пользователей ушли. А так постоянно приходилось чистить настройки в хранилище пользовательских настроек, т.к. в форму попасть было невозможно. Думаю, что такое решение лучше, чем городить регистр, пересчитывать все даты по каждому этапу, которых у одного заказа может быть десятки тысяч, делать новые роли, писать регламентные задания и т.д. и т.п.
16. ivanov660 3545 24.05.22 18:30 Сейчас в теме
(15)
1. Вы поставили вопрос - "как сделать чтобы сортировка работала быстро?" как требование, мы на него ответили.
2. Вариант с отключением возможности сортировки - это отличный вариант.
3. Смысла выкладывать план в текущей ситуации не вижу. Решение есть, вопрос закрыт. Возможно кому-то пригодится идея.

Резюмирую варианты решения (у них есть свои плюсы и минусы):
1. Оставляем как есть.
2. Отключаем возможность сортировки. Нет возможности - нет проблемы
3. Добавить регистр для хранения расчетных дат.
18. PerlAmutor 127 24.05.22 18:37 Сейчас в теме
(16) Вопрос я так не ставил ) Лишь спросил что с этим можно сделать. Была надежда, что запрос можно как-то переписать, чтобы эта сортировка выполнялась уже после TOP 40 например, а не ДО. Может решение с временными таблицами есть, которые можно использовать в динамических списках не так давно? Например отобрать туда результат, а потом уже сортировать? Или во временную таблицу попадет вся таблица, а не результат динамического списка?
20. ivanov660 3545 24.05.22 19:42 Сейчас в теме
(18)
Во временную таблицу попадет весь список. И это похоже будет очень большая таблица, что не очень здорово. Но потом сортировка будет идти веселее.
8. s22 19 24.05.22 09:44 Сейчас в теме
Двойная точка не проблема.
проблема составные типы.
19. PerlAmutor 127 24.05.22 18:38 Сейчас в теме
(8) Я и не говорил, что проблема в двойной точке как таковой. Просто это звоночки. Сегодня "Ссылка" это не составной тип, а завтра уже составной например, а путь от этого не изменится на форме.
9. s22 19 24.05.22 14:32 Сейчас в теме
(5)
Суть проблемы. В динамическом списке есть настройка упорядочивания по полю "ДатаНачала". Но это поле вычисляемое, как следствие не индексируется. Если в БД огромное количество этапов (десятки миллионов), то со списком становится невозможно работать, т.к. любая прокрутка подвешивает пользователя не минуты. Хуже того, этот список имеет настройку автообновления, что приводит к тем же результатам.


добавите реквизит в документ с индексацией?
11. ivanov660 3545 24.05.22 15:34 Сейчас в теме
(9) Каждое решение имеет свои плюсы и минусы.

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

Думаю, что самый быстрый вариант - создать таблицу-регистр сведений, где будут отражены все рассчитанные данные и выводить ее на экран. Но в замен мы будем вынуждены ее пересчитывать ее часть регламентом или при проведении каждого документа.
13. s22 19 24.05.22 17:58 Сейчас в теме
(11)
Думаю, что самый быстрый вариант - создать таблицу-регистр сведений, где будут отражены все рассчитанные данные и выводить ее на экран. Но в замен мы будем вынуждены ее пересчитывать ее часть регламентом или при проведении каждого документа.


тут динамический список с десятками миллионов записей, отборами и сортировкой по полю из регистра сведений.
не уверен, что план будет разумным со стороны планировщика
14. ivanov660 3545 24.05.22 18:13 Сейчас в теме
(13) Будет. Вы в своем утверждении смешали два понятия новый регистр и существующий запрос. Приведу пример для наглядности:
ВЫБРАТЬ
    Новый.Статус КАК Статус,
    Новый.Распоряжение КАК Распоряжение,
    Новый.Подразделение КАК ПодразделениеДиспетчер,
    Новый.НаименованиеЭтапа КАК НаименованиеЭтапа,
    Новый.ПроизводствоНаСтороне КАК ПроизводствоНаСтороне,
    Новый.Подразделение КАК Подразделение,
    Новый.Спецификация КАК Спецификация,
    Новый.ПартияПроизводства КАК ПартияПроизводства,
    Новый.ТребуетсяПланироватьГрафик КАК ТребуетсяПланироватьГрафик,
    Новый.ТребуетсяОбеспечение КАК ТребуетсяОбеспечение,
    //....
    Новый.ДатаНачала КАК ДатаНачала,
    Новый.ДатаЗавершения КАК ДатаЗавершения,
    //....
ИЗ
    РегистрСведений.НовыйРегистр как Новый
Показать
21. s22 19 26.05.22 10:29 Сейчас в теме
(14)
(13) Будет. Вы в своем утверждении смешали два понятия новый регистр и существующий запрос. Приведу пример для наглядности:


Понял. В такой постановке я был не прав. Спасибо за разъяснение
7. ivanov660 3545 24.05.22 08:38 Сейчас в теме
Было бы интересно услышать мнение вендора. А проблемных мест в топовой конфигурации и ее сателлитах еще достаточно.
Gilev.Vyacheslav; +1 Ответить
10. Dach 350 24.05.22 14:45 Сейчас в теме
(0) О, эта дурацкая форма "Мои задачи", тоже с ней намучался. Она тормозит во многих конфигурациях и не только на Pg, но и на Ms sql
Дмитрий74Чел; +1 Ответить
12. ivanov660 3545 24.05.22 15:37 Сейчас в теме
(10) Да, в ней RSL серьезно кривит и размер таблицы тоже быстро становиться большим. Наверное самый оптимальный вариант - это выборочно включить для данного объекта новый механизм ограничения прав доступа.
Gilev.Vyacheslav; +1 Ответить
17. PerlAmutor 127 24.05.22 18:31 Сейчас в теме
Вот сегодняшний кейс, если кому интересно. В документах начал долго выполняться подбор Назначений.
У нас этот справочник огромный за счет количества этапов производства, которые прописываются в назначения.

На скрине проблемное место (Справочник.Назначения.МодульМенеджера.ЗаполнитьДанныеВыбора()). Идет поиск подстроки по шаблону "%%", т.е. подстрока никогда не попадет в индекс. Пришлось поменять на:

Запрос.УстановитьПараметр("СтрокаПоиска", Параметры.СтрокаПоиска + "%");


По началу строки ищется миллисекунды, а не минуты.
Прикрепленные файлы:
Drivingblind; Dach; ivanov660; +3 Ответить
22. Jimbo 9 26.05.22 20:27 Сейчас в теме
Интересно и познавательно как всегда у автора
23. m1_1976 13 30.05.22 16:32 Сейчас в теме
Даже если процентов 10 из выложеннного автором понять, разобрать и внедрить у себя. Уже низкий поклон ему.
Спасибо большое.
24. ivanov660 3545 30.05.22 16:57 Сейчас в теме
(23)
1. Пожалуйста)
2. В примерах указаны точки возникновения и вариант исправления, т.ч. если у вас такая ошибка присутствует, то можете исправить согласно рекомендации. Может разработчики компании 1С ERP конфигурации снизойдут до нас и поправят в последних версиях.
3. Осознать написанное, конечно, это лучше всего. Поэтому рекомендую сначала ознакомиться с тремя предыдущими статьями (в порядке следования):
- Распространенные ошибки разработчиков, приводящие к проблемам производительности
- Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности
- Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

и другие статьи на текущем ресурсе.
25. Serg O. 201 01.06.22 08:51 Сейчас в теме
Спасибо за статью, как всегда очень круто, масса примеров и объяснений, прямо пример для всех.
Оставьте свое сообщение

См. также

Долго открывается конфигуратор Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

В ОС Windows Server 2012 бывает полезно выключать службу Dynamic Fair Share Scheduling (DFSS позволяет балансировать и распределять ресурсы между пользователями), чтобы повысить производительность 1С:Предприятие 8 в ряде случаев.

22.04.2015    45936    Gilev.Vyacheslav    1    

Workaround me в 1С/MS SQL и не только, системный подход к созданию костылей

HighLoad оптимизация Администрирование СУБД v8 Бесплатно (free)

Workaround свидетельствует о невозможности решить проблему "правильным путем" и вызывает чувство стыда. Но практика показывает, что способность решать проблемы через workaround является порой единственным способом решить проблему в разумное время. А победителей, как говорят, не судят, так почему бы не создавать workaround по системе?

15.08.2022    358    1CUnlimited    0    

Ускорим проведение в 1С:Управление холдингом

HighLoad оптимизация Запросы v8 УХ Бесплатно (free)

В 1С:Управление холдингом есть "нехороший" запрос, который съедает значительную часть времени проведения документов. Если его подправить, то проведение заметно ускорится.

10.08.2022    3198    sapervodichka    41    

Миссия невыполнима. Общие реквизиты разделители против временных таблиц

HighLoad оптимизация Механизмы платформы 1С v8 1cv8.cf Бесплатно (free)

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

05.08.2022    821    1CUnlimited    0    

Видеодемонстрация применения Теста-центра для нагрузочного тестирования конфигураций Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

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

16.09.2012    36983    Aleksey.Bochkov    29    

Методика похудения для 1С – 100%

Свертка базы HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Удаление архивных данных из базы - это непростая задача как для 1С, так и для любой базы данных. В статье изложены различные способы решения задачи, включая самый эффективный для 1С.

28.07.2022    3387    1CUnlimited    37    

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

HighLoad оптимизация Технологический журнал Мониторинг Запросы v8 ERP2 УТ11 КА2 Бесплатно (free)

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

20.07.2022    2808    ivanov660    17    

Экспертный кейс. История расследования одного небыстрого закрытия месяца в 1C:ERP. Пример неочевидных путей расследования в виде детективной истории

HighLoad оптимизация Механизмы платформы 1С Запросы v8 ERP2 Бесплатно (free)

В данной статье хотим рассказать об одном нашем непростом расследовании, в котором удалось собрать сразу несколько проблем на разных уровнях инфраструктуры заказчика и изначальной методологии ведения учета. Само расследование в какой-то момент стало напоминать детективную историю, с роялями в кустах, ошибками платформы, странным поведением пользователей и магическим поведением хорошо знакомых механизмов. Но мы реалисты, поэтому все проблемы были выявлены и устранены ;)

11.07.2022    3936    it-expertise    27    

Как можно "положить" SQL сервер с помощью обычной консоли запросов 1С Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Описано как из 1С, с помощью безобидной на первый взгляд обработки, можно сделать неработоспособным SQL сервер. Предложены меры, позволяющие избежать этого.

22.01.2014    70694    yuraos    112    

Производительный режим работы RLS

HighLoad оптимизация Роли и права v8 8.3.14 8.3.6 8.3.8 ERP2 БП3.0 КА2 Бесплатно (free)

Функционал подсистемы УправлениеДоступом позволяет работать с RLS в двух режимах: стандартном и производительном. Каждый из режимов имеет свои преимущества и недостатки относительно другого. Основные из них будут рассмотрены в данном материале.

14.06.2022    2833    Neti    6    

Любовь. Быстродействие. 1С

HighLoad оптимизация v8 Бесплатно (free)

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

26.05.2022    2875    vasilev2015    20    

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

HighLoad оптимизация Администрирование СУБД v8 8.3.14 ERP2 Россия Бесплатно (free)

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

24.05.2022    2999    avolsed    15    

Ускоряем списание партий УПП 1.2 / 1.3 / УТ 10.3 Промо

HighLoad оптимизация v8 УТ10 УПП1 Бесплатно (free)

Не секрет, что многие пользователи, использующие партионный учет (а таких очень много, даже среди огромных холдингов, несмотря на пропаганду РАУЗ) при больших нагрузках сталкиваются с резким замедлением списания партий.

21.06.2013    60174    Антон Ширяев    117    

Заметки эксперта. Расследование длительного выполнения отчета “Движение ТМЦ и затрат в производстве” (1С:ERP 2)

HighLoad оптимизация v8 ERP2 Бесплатно (free)

Кратко: в ходе проведения нагрузочного тестирования “1С:ERP 2” под ОС Linux на СУБД Postgres выявлено существенное замедление формирования отчета “Движение ТМЦ и затрат в производстве” - до 60 минут. После проведенного расследования и точечной корректировки СКД в отчете, без изменения бизнес-логики результатов его работы, работа отчета была ускорена в 80 раз - средний показатель формирования составил 30 секунд.

19.05.2022    1606    it-expertise    19    

Тестирование - игровое моделирование

HighLoad оптимизация Тестирование QA v8 Бесплатно (free)

Мы рассмотрим подход к тестированию с применением элементов искусственного интеллекта

25.04.2022    1048    ivanov660    0    

Несколько слов про платформенный механизм оптимизации RLS

HighLoad оптимизация v8 Бесплатно (free)

Смотрим, как работает платформенный механизм оптимизации RLS, сравним поведение на разных СУБД MS SQL, Postgres 11,13,14.

07.04.2022    2938    ivanov660    21    

Сравнение скорости работы 1C+MSSQL и файлового варианта Промо

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

На форумах постоянно задается один и тот же вопрос: почему 1C+MSSQL медленнее обрабатывает запросы чем файловая? Затем обычно идет «флуд» на несколько десятков страниц. Есть два популярных «течения» в таких форумах — одни говорят что для клиент-серверного варианта это нормально, файловый вариант всегда должен работать быстрее, другие говорят что 1С плохо работает с субд. В результате «баталий и выяснения отношений» на форумах люди расходятся при своих мнения.

19.02.2013    62414    Gilev.Vyacheslav    46    

Почему после обновления Бухгалтерии в марте 2022 года отчеты стали такими медленными

HighLoad оптимизация v8 v8::БУ БП3.0 БУ Бесплатно (free)

Статья раскрывает причину, почему время формирования отчетов после обновления Бухгалтерии в марте 2022 сильно увеличилось. И рассказывает, как можно исправить ситуацию.

05.04.2022    3712    DBOdin_Lab    30    

Экспертный кейс. Расследование фатального замедления времени расчета себестоимости в 1С:ERP 2

HighLoad оптимизация Механизмы типовых конфигураций Запросы v8 ERP2 Бесплатно (free)

При выполнении нагрузочного тестирования информационной системы на базе 1С:ERP для одного из клиентов с целью оценки возможности миграции системы на PostgreSQL и Astra Linux мы столкнулись с неприемлемым увеличением времени выполнения расчета себестоимости. Строго говоря, сценарий тестирования закрытия месяца не был выполнен вообще – он не укладывался в таймаут выполнения теста, 24 часа. По прошествии 18 часов всё ещё шло выполнение операции «Распределение затрат и расчет себестоимости». Более 16 часов выполнялся подэтап “Расчет партий и себестоимости. Этап. Расчет себестоимости: РассчитатьСтоимость”. Всё это время выполнялся запрос, который в текущей инфраструктуре клиента (СУБД MS SQL Server) выполняется чуть более 3 минут на аналогичных данных.

25.03.2022    3892    it-expertise    92    

Экспертный кейс. Расследование деградации производительности системы. Проведение документа “Поступление товаров и услуг” (1С:ERP 2)

Механизмы платформы 1С Запросы HighLoad оптимизация v8 ERP2 Бесплатно (free)

В ходе проведения нагрузочного тестирования одним из наших клиентов была выявлена сильная деградация производительности системы в целом и, в частности, выполнения ключевой операции “Проведение документа поступление товаров и услуг” в течение выполнения теста. Согласно данным подсистемы БСП “Оценка производительности”, время выполнения ключевой операции “Проведение документа поступление товаров и услуг” возрастало в процессе тестирования с 15-20 секунд в начале тестирования до 150-200 секунд в его финале.

02.03.2022    3210    it-expertise    47    

Параллельные вычисления в 1С 8 Промо

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

Решение позволяет ускорять выполнение запросов в 1С 8 в отчетах путем их параллельного выполнения в разных потоках.

11.02.2013    38693    gallam99    19    

Пример пошагового решения проблемы производительности на базе Postgres SQL с картинками

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

Рассмотрим по шагам процесс обнаружения, анализа и решения проблемы производительности на примере базы ERP, сравним отличия в работе Postgres и MS SQL.

28.02.2022    8613    ivanov660    18    

Ускорение работы конфигуратора 1С с большими прикладными решениями

HighLoad оптимизация v8 Бесплатно (free)

Ускорение работы 1С конфигуратора с большими прикладными решениями путем размещения системных каталогов 1С на RAM диске.

13.01.2022    5993    stg2005    105    

Ошибка производительности при проведении этапа 2.2 в ERP 2.4 и ERP 2.5

HighLoad оптимизация v8 ERP2 Россия Бесплатно (free)

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

06.12.2021    1322    Rokky78    6    

Ubuntu vs CentOS vs Win2k8 vs Debian: производительность PostgreSQL Промо

Статистика базы данных HighLoad оптимизация v8 Бесплатно (free)

Хотя интернет уже переполнен статьями о "правильной" настройке связки PostgreSQL и 1C 8.2, для подводных камней всегда остается место. При сравнении производительности СУБД PostgreSQL на разных ОС, показатели различаются в разы. Самую большую обиду принесла любимая Ubuntu (человечность). После долгих дней и ночей проведенных за консолью этой ОС, она разочаровала окончательно. Тормоза PostgreSQL в Ubuntu Server. Что с ними делать? Сколько раз можно наступать на грабли?

03.11.2012    45856    madmpro    32    

Повышение производительности веб-сервисов. Переиспользование сеансов

WEB HighLoad оптимизация v8 Бесплатно (free)

Повышение производительности веб-сервисов. Переиспользование сеансов. Практическая реализация.

20.10.2021    3314    sorter1    2    

Оптимизация проведения документов списания партий в УПП 1.3

HighLoad оптимизация v8 УТ10 УПП1 Бесплатно (free)

Почти в каждой конфигурации УПП 1.3 (возможно, и в УТ 10.3) есть медленный запрос, тормозящий проведение документа списания. Данная публикация раскрывает места вызова данного запроса и приводит пример оптимизации. Пример показывает результаты проведения документа «Реализация товаров и услуг», но метод работает и для других документов списания партий.

09.09.2021    1065    info1i    5    

Смотрим запросы 1С через Microsoft SQL Profiler по следам ошибок разработчиков, приводящих к проблемам производительности

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

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

07.09.2021    8659    ivanov660    26    

Адекватный параллелизм в 1С

HighLoad оптимизация v8 Бесплатно (free)

Параллелизм ускоряет выполнение тяжелых регламентных операций на СУБД, но может негативно влиять на работу многопользовательских учетных систем. О том, как анализировать влияние параллелизма и настраивать его для MS SQL и PostgreSQL, рассказал ведущий разработчик компании ООО МКК «Ваш Инвестор» Вадим Фоминых.

13.08.2021    8698    Shmell    7    

Распространенные ошибки разработчиков, приводящие к проблемам производительности

HighLoad оптимизация Рефакторинг и качество кода v8 Бесплатно (free)

Рассмотрим примеры ошибок, анализ, исправление и мероприятия по недопущению подобного в будущем. Всего будет 18 примеров.

02.08.2021    13247    ivanov660    77    

Parameter sniffing и генерация планов для разработчиков 1С

HighLoad оптимизация v8 Бесплатно (free)

Особенности генерации планов запросов. Статья написана по мотивам вебинара Виктора Богачева.

01.06.2021    12261    vasilev2015    17    

Поиск причин блокировок СУБД

HighLoad оптимизация v8 v8::blocking 1cv8.cf Бесплатно (free)

Расследование блокировок СУБД. Статья написана по мотивам вебинара Виктора Богачева.

28.04.2021    7070    vasilev2015    13    

Тонкости эксплуатации, плюшки и особенности Postgres Pro Enterprise

HighLoad оптимизация v8 1cv8.cf Россия Бесплатно (free)

В ходе онлайн-встречи INFOSTART MEETUP Novosibirsk Руководитель ИТ из компании ИнфоСофт Антон Дорошкевич поделился с коллегами тонкостями и опытом работы с Postgresql для 1С. 

22.04.2021    5353    a.doroshkevich    6    

Решение нестандартных проблем производительности на реальных примерах

HighLoad оптимизация v8 Бесплатно (free)

На екатеринбургском Infostart Meetup выступил с докладом архитектор ИС центра разработки ФТО Александр Криулин. Он поделился с коллегами кейсами нестандартных проблем производительности и рассказал о способах их решения.

24.03.2021    6538    AlexKriulin    37    

Соединение вложенными циклами

HighLoad оптимизация v8 Бесплатно (free)

Nested loops и отсутствующие индексы. Статья написана по мотивам вебинара Виктора Богачева.

12.03.2021    4302    vasilev2015    22    

Долгое воспроизведение звука по RDP с удаленной машины

HighLoad оптимизация v8 Бесплатно (free)

При воспроизведении короткого звука в 38 Кб, сигнализирующего об успешном сканировании, порою происходило подвисание примерно в 5 секунд.

09.02.2021    1339    pashamak    2    

Анализ блокировок СУБД: таблица изменений плана обмена 1С

HighLoad оптимизация v8 Бесплатно (free)

Практический пример анализа типичной проблемы ожидания на блокировках СУБД, возникающих при использовании планов обмена 1С. Сервер СУБД: Microsoft SQL Server.

18.12.2020    4682    zhichkin    11    

Анализ проблем производительности по динамике мониторинга RAS 1C

HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

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

07.10.2020    6349    ivanov660    13    

Ускорение медленной работы строк в 1С на примере 1С:Документооборот КОРП

HighLoad оптимизация v8 ДО Бесплатно (free)

Если у вас в 1С:Документооборот КОРП 2.1.11.5 (часть более старых и новых конфигураций): 1) Долго отправляется почта в формате HTML; 2) Медленно открывается документы внутренние / входящие / исходящие; 3) Тормозит область просмотра или открытие задач. Тогда вам сюда.

02.10.2020    6234    Iaskeliainen    16    

Тест скорости работы мобильной платформы 1С

Мобильная разработка HighLoad оптимизация v8 1cv8.cf Бесплатно (free)

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

14.09.2020    2431    capitan    25    

Нестандартные блокировки при работе с OLAP-нагрузкой

HighLoad оптимизация v8 Бесплатно (free)

Если выполнение отчета мешает работе других пользователей и провоцирует блокировки, даже с учетом «грязного чтения» – ситуация кажется парадоксальной. О том, как расследовать такие проблемы, на конференции Infostart Event 2019 Inception рассказали ведущий программист торгового дома «Петрович» Станислав Щербаков и специалист по производительности компании «СофтПоинт» Александр Денисов.

20.07.2020    3116    Филин    7    

[SQL Server] Использование trace flag 9592 для сжатия траффика в кластере AlwaysOn

HighLoad оптимизация v8 Бесплатно (free)

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

18.05.2020    2971    Aleksey.Bochkov    4    

Эти занимательные временные таблицы

HighLoad оптимизация Администрирование СУБД v8 Бесплатно (free)

Кое-что интересное о временных таблицах и работе платформы 1С с ними.

06.04.2020    20928    YPermitin    0    

Оптимизация запросов 1С посредством индексации временных таблиц. Миф? Тестируем, смотрим, считаем

HighLoad оптимизация v8 Бесплатно (free)

Появилось свободное время, решил проверить на работе индексацию таблиц. Решил поделиться с Вами результатами исследования. Давайте порассуждаем на эту тему? Часто ли вы пользуетесь индексацией в запросах? Платформа 8.3.16.1224

03.04.2020    11411    feva    15    

Как я собрал для себя высокопроизводительный и бесплатный облачный бекенд для 1С на PosgreSQL + PostgREST

HighLoad оптимизация WEB Мобильная разработка Администрирование веб-серверов v8 Бесплатно (free)

В этой статье я расскажу о проблемах бека для мобильных приложений или другого фронта, который требует производительности, быстрой реакции и отказоустойчивости, и как я решил это благодаря opensource проекту PostgREST и СУБД Postgre SQL 12. Проведу простой тест производительности для сравнения 1С с данным решением. Это может быть полезно всем, кто разрабатывает мобильные приложения либо фронтсайд-приложения для 1С на чем угодно - на мобильной платформе или на нативном языке или на Simple UI. И также обзор новых функций SimpleUI для связи с этим бекендом.

31.03.2020    17416    informa1555    35    

Многострочный контекст событий

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

Разбор технологического журнала с группировкой событий по первой или последней строке многострочного контекста.

31.03.2020    4302    vasilev2015    12    

Анализ взаимоблокировок

HighLoad оптимизация Технологический журнал v8 v8::blocking Бесплатно (free)

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

20.03.2020    8272    vasilev2015    40