база УТП для Украины (аналог КА)
после перехода на клиент-серверный вариант работы стали долго (6-10 минут) проводиться некоторые документы "Отчет о розничных продажах"
Замер производительности показывает что очень долго выполняется запрос:
http://savepic.net/10164459.htm
Запрос простой до безобразия, на скрине показаны замеры на двух "соседних" документах, но проблема в том что документ, который перед этим провелся нормально, при перепроведении так же тупит :(
1С 8.3.10.2561. Пробовал на 8.3.9.2233
MS SQL 2012 SP2
пробовал на боевом сервере (Сервер 1С на виртуалке, SQL на железе) и на тестовом сервере (все на железе, на одном сервере, я во время теста на сервере был один) - разницы нет, так что дело не в железе
ТиИ прогонял. Не помогло
SELECT TOP 10 *
  FROM [MyBase].[dbo].[_InfoRg13775]
  WHERE _Period IS NULL
пустой (InfoRg13775 - Регистр сведений ЦеныАТТ)

куда еще посмотреть???? :(
На файловой, ожидаемо, летает...

Всё на Украине не слава богу...

(0)составной тип значения в измерениях есть?

(1) Давайте без политики, пожалуйста.
(2) Склад, Номенклатура, ХарактеристикаНоменклатуры, все с типами соответствующих справочников. Не составные. Больше измерений нет

(0) профайлер, планы запроса что говорят?
(3) Украина без политики - это фантастика.

(3)мошт скуль тупит
регламентные операции на скуле настроены?

А статистику обновляли?

Проиндексируй измерения Номенклатура и Склад

(0)а что в списках складов и номенклатуры, мошт там треш?

(0)
Список номенклатуры, склад во временную таблицу, проиндексировать

в виртуальной
(Склад, Номенклатура) В (Выбрать ВрТаб.Склад, ВрТаб.Номенклатура ИЗ ВрТаб)

Если организация есть, ее тоже добавить

(5) мошт скуль тупит
вполне возможно, даже скорей всего. Но одинаково тупят 2 скуля  на двух серверах...
(6) А статистику обновляли?
Да, забыл указать. После обновления статистики один-два документа проводятся норм. дальше тупняк даже при перепроведении тех же. Но не обновлять же статистику после каждого документа...
(8) Нет там треша. Да и один и тот же документ в одной и той же базе проводится то пару сек. то 10 мин.
(7) Прямо в регистре? или для начала как в (9). Кстати Номенклатуру в регистре индексировать не дает (Стоит галка "Ведущее")

(9) Утром с этого начну. Сейчас нужно бежать, если есть еще мысли - кидайте

(10) Прямо в регистре

(11) Вы не победите, пока план запроса в xml не соберете. Вот и все мысли.

(11) если вариант (Склад, Номенклатура)
то номенклатуру можно не индексировать - там уже есть индекс по набору измерений

В складах ровно 5 элементов, стоит индексировать?
А Номенклатуру, напомню, индексировать не дает

(15) Убери отбор по складу

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

ВЫБРАТЬ
    Номенклатура.Ссылка КАК Номенклатура,
    Склады.Ссылка КАК Склад
ПОМЕСТИТЬ НоменклатураСклад
ИЗ
    Справочник.Номенклатура КАК Номенклатура
        ЛЕВОЕ СОЕДИНЕНИЕ Справочник.Склады КАК Склады
        ПО (Склады.Ссылка В (&СписокСкладов))
ГДЕ
    Номенклатура.Ссылка В(&СписокНоменклатуры)

ИНДЕКСИРОВАТЬ ПО
    Номенклатура,
    Склад
;

////////////////////////////////////////////////////////////////////////////////
ВЫБРАТЬ
    ЦеныНоменклатурыСрезПоследних.Номенклатура,
    ЦеныНоменклатурыСрезПоследних.Цена
ИЗ
    РегистрСведений.ЦеныАТТ.СрезПоследних(&Дата
            ,
            (Номенклатура, Склад) В
                (ВЫБРАТЬ
                    НоменклатураСклад.Склад,
                    НоменклатураСклад.Номенклатура
                ИЗ
                    НоменклатураСклад)) КАК ЦеныНоменклатурыСрезПоследних

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

Самый оптимальный вариант, сделать вирт.таблицу - реальной.
делаете второй непериодический регистр сведений копию нужного с таким же названием и приставкой например Текущие, (БлаБла_Текущие).
Добавляете подписку на запись периодического регистра
пример для ЦеныНоменклатуры
----
Процедура РегистрСведений_ПриЗаписиЦены(Источник, Отказ, Замещение) Экспорт
        
    Если Не Отказ Тогда
        Для Каждого Запись Из Источник.ЭтотОбъект Цикл
            //При каждом изменении цен Обновляем таблицу текущих цен
            Запрос = Новый Запрос;
            Запрос.Текст =
            "ВЫБРАТЬ
            |    ЦеныНоменклатурыСрезПоследних.Номенклатура,
            |    ЦеныНоменклатурыСрезПоследних.ВидЦены,
            |    ЦеныНоменклатурыСрезПоследних.Характеристика,
            |    ЦеныНоменклатурыСрезПоследних.Цена,
            |    ЦеныНоменклатурыСрезПоследних.Упаковка,
            |    ЦеныНоменклатурыСрезПоследних.Валюта
            |ИЗ
            |    РегистрСведений.ЦеныНоменклатуры.СрезПоследних(
            |            ,
            |            Номенклатура = &Номенклатура
            |                И ВидЦены = &ВидЦены
            |                И Характеристика = &Характеристика) КАК ЦеныНоменклатурыСрезПоследних";
            
            Запрос.УстановитьПараметр("ВидЦены", Запись.ВидЦены);
            Запрос.УстановитьПараметр("Номенклатура", Запись.Номенклатура);
            Запрос.УстановитьПараметр("Характеристика", Запись.Характеристика);
            
            РезультатЗапроса = Запрос.Выполнить().Выгрузить();
            
            НоваяЗапись = РегистрыСведений.ЦеныНоменклатурыТекущие.СоздатьМенеджерЗаписи();
            НоваяЗапись.Номенклатура =  Запись.Номенклатура;
            НоваяЗапись.ВидЦены =  Запись.ВидЦены;
            НоваяЗапись.Характеристика =  Запись.Характеристика;
            
            Если РезультатЗапроса.Количество() > 0 Тогда
                НоваяЗапись.Цена =  РезультатЗапроса[0].Цена;
                НоваяЗапись.Валюта =  РезультатЗапроса[0].Валюта;
                НоваяЗапись.Упаковка =  РезультатЗапроса[0].Упаковка;
                НоваяЗапись.Записать();
            иначе
                НоваяЗапись.Удалить();
            КонецЕсли;
                
        КонецЦикла;
        
    КонецЕсли;
    
КонецПроцедуры
----
Правите нужны запросы на новую таблицу. Делаете первичное заполнение и наслаждаетесь необыкновенно высокой скоростью

(19) Откройте для себя ИтогиПоСрезуПоследних. Вылезайте уже из каменного века.

или вот более универсальный пример, добавляем в модуль периодического регистра
Процедура ПриЗаписи(Отказ, Замещение)
    Если Не Отказ Тогда
        Для Каждого Строка Из ЭтотОбъект Цикл
            Запись = РегистрыСведений.ЦеныТекущие.СоздатьМенеджерЗаписи();
            ЗаполнитьЗначенияСвойств(Запись, Строка, , "Период");
            Запись.Записать();
        КонецЦикла;
    КонецЕсли;
КонецПроцедуры

(19) Ну и вспомните, что нужны и неоперативные записи.

Но у автора - другая проблема. Проблема с SQL

Особенно позабавил вариант (18). Образчик прям ядского треша.

(20) (22) а вы сравнивали  скорость работы ИтоговПоСрезуПоследних и регистра сведений с расчетом среза последних  при записи?
В особо клинических случаях, помогает даже с регистрами накоплений.
в базах большим количеством изменений разница ОЧЕНЬ существенна.

(25) + регистры сведений позволяют присоединять их через ПВХ как характеристики товаров, т.е. к примеру присоедениить все виды цены или остатки по складам к номенклатуре как свойства. А затем легко использовать их в дин.списках и отчетах

(25) "а вы сравнивали  скорость работы ИтоговПоСрезуПоследних и регистра сведений с расчетом среза последних  при записи? "

Нет. Не сравнивал, так как это - одно и тоже, только 1 вариант - это платформенная фишка и как бы нет необходимости самому пилить костыль.

А что - вы сравнивали?

Про РегНакопления - нифига не понял.

(24)
Я так понимаю провели замеры ?
Или так - пальцы покидать

(28) Конечно провели.

(0) 1. Запустить реиндексацию базы. Чтобы привести в порядок индексы. Вы дергали галочки индексации или ведущих измерений? Они сами не встанут, только после переиндексации. Может вы и порядок измерений меняли? Возможно, кластерный индекс перестроился при обновлении конфигурации ИБ, возможно нет.

2. Что характеристика номенклатуры вообще делает в регистре??? Если она еще и измерением является - совсем плохо. Используй конструкцию "Выразить". Это облегчит агонию ИБ.

3. PS я б ничего не индексировал, если номенклатура со складом первые 2 измерения регистра. Если это не так - подвинуть их в начало.

4. Уволиться.

https://naf2000.blogspot.ru/2013/09/1-8_11.html

(0) Сколько сотен тысяч записей в РС?
Помню, на подобную ситуацию натыкался - в РС: 600К записей, всего 3 измерения. Делаем срез с отбором по одному измерению - занимает 20 минут. Делаем срез без отбора - работает быстро. Я так и не разобрался в чем проблема.
Прямо интересно

(32) план запроса разный

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

(32) стыдно сказать, 8321

(32) Скорее всего нужно переиндексировать и/или пересоздать итоги.

(34)как определил что это постгри?

Можно создать ещё один регистр, который назвать ЦеныСрезПоследних.
При записи основного регистра (или с какой-то регулярностью) обновлять второй.
Запрос ко второму регистру сведений будет моментальный.

(37) Ну он же сказал "Постгри не виноватый"
Сделал то, что очень не рекомендуют авторы всех книжек по запросам: Перенес условие из параметров виртуальной таблицы в обычное условие
    ТекстЗапроса = "ВЫБРАТЬ
                   |    ЦеныПродажные.Склад КАК Склад,
                   |    ЦеныПродажные.Номенклатура КАК Номенклатура,
                   |    ЦеныПродажные.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
                   |    ЦеныПродажные.Цена КАК Цена
                   |ИЗ
                   |    РегистрСведений.ЦеныАТТ.СрезПоследних(&Дата, Склад В (&СписокСкладов)) КАК ЦеныПродажные
                   |ГДЕ
                   |    ЦеныПродажные.Номенклатура В(&СписокНоменклатуры)";
Что-то похожее рекомендовали выше но с ВТ и индексами. Летает.
Все равно остается вопрос как скуль заставить строить здравые планы не только при первом проведении после Update statistics, но и весь день...

(39) лучше внутри скобок оставь отбор по номенклатуре

(39) Дополнять список номенклатуры пустыми позициями до 1000 штук. тогда
Номенклатура В(&СписокНоменклатуры) всегда будет конвертироваться в _field IN (&P1,...&P1000) и план для таких запросов будет один.

(40) Но тогда включаются тормоза :(
а так

00000000221 Время проведения - 4
00000000222 Время проведения - 5
00000000225 Время проведения - 4
00000000217 Время проведения - 5
00000000218 Время проведения - 4
00000000219 Время проведения - 4
00000000220 Время проведения - 5
00000000221 Время проведения - 3
00000000222 Время проведения - 4
00000000223 Время проведения - 5

Неидеально, но далеко не 10-15 минут
Теперь заставить бы скуль здраво строить планы с отбором в скобках...

(42) Сделай в регистре измерение Номенклатура первым.

Если список номенклатур большой, то IN работает плохо и возможно стоит сделать примерно так:

ВЫБРАТЬ
   Номенклатура

ПОМЕСТИТЬ тзНоменклатуры

ИЗ
  &тзСписокНоменклатур КАК тзНоменклатуры

ИНДЕКСИРОВАТЬ ПО
  Номенклатура
;

ВЫБРАТЬ
    ЦеныПродажные.Склад КАК Склад,
    ЦеныПродажные.Номенклатура КАК Номенклатура,
    ЦеныПродажные.ХарактеристикаНоменклатуры КАК ХарактеристикаНоменклатуры,
    ЦеныПродажные.Цена КАК Цена
ИЗ
    РегистрСведений.ЦеныАТТ.СрезПоследних(&Дата, Склад В (&СписокСкладов)) КАК ЦеныПродажные

    СОЕДИНЕНИЕ тзНоменклатур
      ПО ЦеныПродажные.Номенклатура = тзНоменклатур.Номенклатура

(44) + план будет одинаковый

(39) Интересно было бы посмотреть результат запроса в PostgreSQL 10, там они с планом запроса плотно поработали. Как раз подходит для 1С. Бартунов видео выложил. Только когда новую версию под 1с выпустят?

(43) Помогло
Возвращаю порядок измерений назад - тормоза возвращаются
Оставлю пока так
Всем спасибо
(44) не то чтоб большой. в проблемных документах приблизительно по 150 строк
Поэкспериментировал с документом на 20 строк - проводится влет, в профайлере при этом один запрос с трудночитаемым для меня планом :(, но одним
При проведении обычного документа на 150 строк в профайлере огромная куча мелких запросов, в которых я просто теряюсь :(
Соответственно и планов куча...

(42) Я надеюсь 4-5 - это секунды :-)

(47) Одной проблемой на Украине меньше... :)

конструкция В() равносильна вроде как отбору по условию ИЛИ. Чем больше элементов в массиве, тем труднее. Потому я взял за правило, что если в массиве не ограниченное и, как правило, не прогнозируемое число элементов, делать через ВТ и последующее соединение большой таблицы с отбором из ВТ. Алгебра множества она такая....

А статистику смотрели по запросу? Может у вас там в регистре до сего дня было 10 записей, а сегодня 50 млн, и запрос всю таблицу сканит (Index scan использует в sql). Смотрели запрос в профайлере? Если план (47) "трудночитаемый" то поставьте в профалере отбор по настройке "SHOWPLAN_XML STATISTICS PROFILE" или как-то так, на память не помню. Он план в xml показывает. После того как покажет вас будет интересовать ожидаемая выборка и действительная в операторе и сами операторы. Запрос в ветке не нашел но проблемы основные могут быть: 1)При связи будет оператор "Nested loops" 2)При поиске в таблице будет "Table scan"или еще какой скан.