Имеем два виртуальных сервера. серверы полные близнецы.

На одном сервере тяжелый тестовый запрос выполняется 4,5 сек. На втором 0,6 сек.

Помогите найти причину.

Версии серверов: 15.0.2093.5 (этот медленный), 15.0.2101.7 (этот шустрее)

Сначала грешил на разные сборки. На тестовом отдельном компьютере проверил эту гипотезу: ставил 3 разные версии с постепенным увеличением версии СКЛ сервера до 15.0.2101.7.
На всех сборках тестовый запрос показывал одно и то же время.

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

Было замечено, что на проблемном и быстром сервере скорость дисковой подсистемы различается.
чтение 540 МБ/с против 380.

Администраторы поменяли виртуалки в кластере местами и теперь на проблемном серваке чтение составляет 540 Мб/с, а на втором 380.
Однако, это повиляло на скорость выполнения запросов примерно на 10 мсек.

Оказалось, что запрос пожирает в большей степени ЦПУ, нежели диск.

Проверил настройки СКЛ серверов запросом
select * from sys.configurations

Настройки одинаковы.

Пока больше не знаю, куда уже и смотреть

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

(1) у нас есть второй сервер прода, на котором также медленно, по сравнению с тестом.
Хочется понять причину.

Забыл уточнить. При замерах времени я использовал время выполнения запроса на стороне СКЛ, т.е. в замерах исключено влияния сервера 1С предприятия на общую картину

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

(4) статистика обновлена перед контрольным замером.
Планы запросов одинаковы до неприличия :-)

(5) То есть планы одинаковые, а временные характеристики исполнения запросов разные? Можешь сюда кинуть фактический план с таймингами?

(6) в xml план?

(7) Хотя бы. Чтобы было на что посмотреть, а не тупо фантазировать.

+(8) Только именно фактический, а не прогнозный план

(9) из хранилища запросов сейчас выдерну.

(0)У меня такое было из-за распараллеливания выполнения запросов. На проде было выключено согласно рекомендациям. На тесте было включено "из коробки". Включил на проде, подобрал стоимость распараллеливания.

(11) параллелиризм выключен на всех серваках

(2) Сделайте полный бэкап быстрого сервера и разверните его на вторую машину. Клонируйте скорость!

(5) Нам то покажите планы.

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

https://habr.com/ru/companies/1cloud/articles/462777/

сравнить

надеюсь у вас одинаковая ось на обоих?

(0) и настройки совпадают и базы околоидентичны и статистика свежая и т.п.?

(16) пока небольшой баг нашелся.

восстановил копию базы с прода на тесте. теперь показывает медленное выполнение запросов :-)

Сейчас пытаюсь найти разницу между базами.

(19) да.

(20) как оказалось, какие-то различия есть. именно в БД.

Запрос 1С

ВЫБРАТЬ РАЗЛИЧНЫЕ
    ВТ_ДанныеДляПодбораОплат.ВалютаВзаиморасчетов КАК Валюта,
    ВТ_ДанныеДляПодбораОплат.КорСчет КАК Счет,
    ВТ_ДанныеДляПодбораОплат.КорСубконто1 КАК Контрагент,
    ВТ_ДанныеДляПодбораОплат.КорСубконто2 КАК ДоговорКонтрагента,
    ВТ_ДанныеДляПодбораОплат.КорСубконто3 КАК ДокументРасчетов
ПОМЕСТИТЬ ВТ_ДанныеДляПодбораОплат
ИЗ
    &ИсходнаяТаблица КАК ВТ_ДанныеДляПодбораОплат
ГДЕ
    ВТ_ДанныеДляПодбораОплат.СуммаБУ < 0 И ВТ_ДанныеДляПодбораОплат.СуммаВзаиморасчетов < 0
;

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

куда план запроса выложить? на какой ресурс?

(23) перетащи базу на другой сервак и сравни результат ещё раз но на идентичных базах

(25) https://explain.tensor.ru/
https://tatiyants.com/pev/#/plans
https://www.brentozar.com/pastetheplan/

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

(27) спасибо

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

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

Это утренняя копия базы и пятничная на одном и том же сервере.

Уже удалось понять, что разница не между серверами, а между копиями БД разных дней.

DBCC freeproccache не помогает

(29) добавь в первой ВТ индекс по самому селективному полю.
ДоговорКонтрагента

А кстати, разве договор не определяет однозначно и контрагента и валюту? Может оставить отбор по одному полю вообще?

(32) там субконто же.
(31) в ВТ всего одна строка

(33) И что? Если одно субконто дает 100% селективность, зачем отбирать и по остальным тоже?

(34) не помню, как там индексы на ВТ указаны.
Оба надо указывать или они по отдельности. Завтра в базе гляну.

(34) Состав индекса по таблицам итогов по счетам так, устроен таким образом, что для попадания в индекс необходимо указать все предшествующие субконто.

(36) И что, попадает? Дает какой-то эффект в плане быстродействия? Пробовали так и эдак, смотрели планы запросов?

(37) когда миллионы записей и обращение к виртуальным таблицам в модуле проведения, то прирост скорости существенный на 50-100 тысячах документов.

(37) кратко, о попадании в индекс.

Вот часть неоптимального запроса

|ИЗ
|    РегистрБухгалтерии.Хозрасчетный.Остатки(
|            &ДатаКорректировки,
|            Счет В ИЕРАРХИИ (ЗНАЧЕНИЕ(ПланСчетов.Хозрасчетный.РасчетыСПокупателямиВал)),
//++Оптимизация попадания в индекс
|            &ВидыСубконтоСчета62,
//++Оптимизация попадания в индекс
|            Организация = &Организация
|                И (Субконто1, Субконто2, Валюта) В
|                    (ВЫБРАТЬ
|                        А.Контрагент,
|                        А.ДоговорКонтрагента,
|                        А.Валюта
|                    ИЗ
|                        ВТ_ДанныеДляПодбораОплат КАК А)) КАК ХозрасчетныйОстатки


После добавления фильтра на виды субконто запрос вместо 4-х секунд стал выполняться за 0,5 секунды.

(39) Какая связь между отбором по видам субконто и фильтром по всем субконто сразу? Одно может быть и без другого.

(40) Я не виноват, так индекс устроен.