Имеется конфигурация Розница для Украины 1.0.7, серверная, win 2012, sql 2014, 1с 8.3.8.1652 (сменил на 8.3.6.2524).после переустановки сервера 2012 начались тормоза при выводе в СКД отчетов. больше всего отображается на валовой прибыли. на моменте 0% висит около часа. раньше отчет исполнялся минут за 10.
В консоли отчетов сам запрос исполняется за считанные минуты.
менял платформу с 8.3.8.1652 на 8.3.6.2524 (на старом сервере была младшая версия). куда дальше копать? в чем может быть проблема????

включи отладку на сервере и выполни замер производительности. Над результатами думай или сюда положи

https://ibb.co/icWiuQ
вот такой результат замера

"на моменте 0% висит около часа. раньше отчет исполнялся минут за 10. " - жесть!
"сам запрос исполняется за считанные минуты." - жесть!

(2) Сервер 1С и сервер SQL - на разных машинах?

(2) Или, хехехе - на разных виртуалках/одном хосте?

(2) а кому вообще нужен отчет из 333 411 строк?

(6) это не количество строк отчета, а количество элементов результата

(7) все равно нехилая портянка получается

(0) время выполнения многих отчётов зависит от объема данных, поэтому и было 10 минут стало 60 может быть нормой. Также для скд злоезло вычислимые поля обращающиеся для вычисления к общим модулям, а также тащить в качестве результата запроса ссылки без крайней нужды (а потом лезть в разименование при компановке ваще писец)

(5) ненавижу виртуалке с безграмотными админа и в одном флаконе

(10) при этом от админа как правило слышно "не учи ученого, это не виртуалка тормозит, это ваша 1С такая кривая".

(11) не обязательно, нам пытались тыкать, что это у нас запросы неоптимальные (в принципе я даже знаю кто из бывших коллег это напел им)

(12) Ну про неоптимальность может быть и правда. Обидно когда речь идет о тормозах вообще всего в виртуалке.

(13) да но на железаке за 250 тыр летает, а на мегациске(из под EXSI) за 3 ляма временами наступает жуткий писец!

(2) Есть подозрение, что это в группировках отчета какие-то ядрёные вычисления для попугайской раскраски строк. Или/и в ресурсах формулы на 100500 строк с применением функций МАССИВ и ВЫБОРКОГДАТОГДА.
Может такое быть?

сервант тут не причем, ковыряйте отчет

(4) серверы на одном физическом компе, но так было и до переустановки винды
(9) объем базы и наполнение тоже существенно не изменилось  (16) и отчет тоже не изменялся, типовый отчет Оценка Валовой Прибыли

(17) ну сказок-же не бывает... а под полными правами формируется быстро?

(18) от прав не зависит

от серванта тоже

(0)
" на моменте 0% висит около часа"
Сними с брикпоинта в конфигураторе, а то он у тебя неделю висеть будет

Из синопсиса до конца непонятно - сама машина менялась или нет физическая?

(21) посмеялся :)
(22) нет , машина не менялась

(23) когда он выводит результат, он совпадает полностью с тем, что выводится в консоли за несколько минут?

Чудес не бывает. Откинуть вообще ситуацию с переустановкой винды и разбираться с проблемой "в консоли отчетов в 10 раз быстрее, чем на базе".

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

Если всё же совпадение таблиц полное, то попробовать в консоли тоже использовать поэлементный вывод ПроцессорКомпоновки.Следующий(), вместо просто ПроцессорКомпоновки.Вывести(). Если окажется, что разница в нём, то можно начинать пляски с бубнами, переустанавливать видеодрайвера и писать в 1С. Ну или переписать вывод.

Воспользуйся отладкой компоновки https://www.youtube.com/watch?v=0LKGaFo9tXw в подсистеме "Инструменты разработчика".
Начни с анализа результирующего запроса. Добейся чтобы он выполнялся за разумное время. Далее уже разбирайся с самой компоновкой и количеством возвращаемых строк.

Если схема или настройки в готовом виде отсутствуют, то в точке останова сделай снимок компоновки через вычисление

ВнешниеОбработки.Создать("<ПутьКПапкеИР>\ирПортативный.epf", Ложь).От(СхемаКомпоновки, НастройкиКомпоновки)

по аналогии с отладкой запроса https://www.youtube.com/watch?v=hiw_aYVOvFc

(25)
"Добейся чтобы он выполнялся за разумное время"

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

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

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

(28)
Мне кажется, ты много ожидаешь от человека, который на мисте спрашивает почему долго выполняется отчет, хотя совет, конечно, правильный.

Анализ производительности стоит начинать от целевого времени.
Тут, видимо, пользователей время в 10 минут устраивает.
Замер показал, что 90% тратится на вывод, это явная неадекватная ситуация.

Моё мнение - нужно сначала определить, что там с выводом.
Потом работать с запросом, профайлером и техжурналом.

хотя и так понятно, 300000 элементов - это какая-то чушь в отчете

(29) Хотя судя по замеру в (2) обработчиков получения представления нет. Они бы там появились.
300000 = (например) 15000 строк * 20 колонок
Так что не такая уж и нереальная ситуация.

(32) По картинке вижу, что начало цикла исполнилось на 1 раз больше, чем конец цикла. Я так понимаю, замер сделан до окончания формирования отчета, т.е. в реальности там может быть сколько угодно элементов.

(32) Отчет на 15000 строк - бесполезный, я настаиваю :)

(34) Если отчет формируется для экспорта в другую инфосистему (например EXCEL) для обработки, то вполне нормальная ситуация.

(33) Да. Вероятно, это только начало вывода. Потому начать поиски следует с усиления отбора на отрезке НастрокиКомпоновки->Запрос, т.е. без выборки данных.

(29) уже писал ему...

(34) не факт, может он выводит группировки и ему прям из отчёта нужна расшифровка

(38) Всего лишь поиском елозить и пейдждауны зажимать на полчаса вместо фильтров и расшифровок, ага.

(35)
Или для налоговой, чтобы они в нём закопались и не вылазили.