Добрый день, коллеги!
Сегодня столкнулся с необычным падением производительности в работе построителя отчета. Ситуация следующая:
1. Старый сервер, на котором сейчас работают все пользователи и на котором больше данных.
 - Выводит отчет за 7 секунд.
2. Новый сервер, на который был произведен тестовый перенос базы неделю назад. Один пользователь в базе. Более мощное железо. Стандартные настройки SQL + 1C.
 - Выводит тот же отчет с теми же параметрами за 23 секунды...

Платформы одинаковые: 1С:Предприятие 8.2 (8.2.16.368)
Обычное приложение.
Конфигурация не типовая.

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

Даже при проверке построителя через отладчик (shift+f9) происходит какая-то пауза секунд в 10.

Сам вопрос:
Кто-нибудь сталкивался с подобным поведением построителя? Если да, то как вы это решили?
Заранее благодарен за любые советы и полезную информацию!
---
Всем спасибо за информацию. Проблема решилась после нескольких процедур, а именно:
1. Тестирование и исправление с реиндексацией таблиц и пересчетом итогов.
2. Настройка взаимодействия 1С и SQL через Shared Memory - без сети через участок памяти. Видимо, не все идеально было при передаче по сети.
3. Прочие нюансы, которые настраивал системный администратор со стороны нового сервера. Всего что он менял не знаю. Были какие-то нюансы с размером блока диска с базой и т.д.

Теперь тот же отчет строится не 23 секунды, а 4. Как-то так...
---
Возможно дело не в постоителе отчетов?
Сколько выполняются другие отчет допустим на скд (большие)?
Птаформа настройки SQL идентичны на серверах?
Индексирование таблиц произведено?
---
Добавлю только

https://infostart.ru/public/193674/

https://infostart.ru/public/91879/

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

Проверьте частоту выполнения фоновых заданий и количество их в базе.
---
Спасибо, ознакомлюсь.
Но дело в том, что в тестовой базе сейчас работает один-две пользователя, которые тестируют ее. На момент проверки отчета - только один.
А фоновые задания полностью отключены, чтобы обмен и прочие выгрузки реальной базы не испортить "левыми" пакетами.
---
Не надо знакомится. То что там описано устарело с выходом 8.3
---
Странно, а мне в 8.3 и помогло.

Вы уверены, в своих выводах.
---
Абсолютно. В 8.3 начиная с версии платформы 8.3.3 (и базы в режиме совместимости 8.2.16 и выше ) режим rcsi( Read Commited Snapshot Isolation) включен по умолчанию. Естественно только для управляемых блокировок.

Режим SNAPSHOT в принципе никогда не использовался в 1С, так что его включение бесполезно.

Вам включение rcsi могло помочь только если конфигурация у вас в режиме совместимости 8.2.13 и ниже.
---
На всякий случай проверьте в свойствах базы

Установлено ли так

ALT ER DATABASE MyDatabase
SET ALLOW_SNAPSHOT_ISOLATION ON

ALT ER DATABASE MyDatabase
SET READ_COMMITTED_SNAPSHOT ON

У меня пользователи резко перестали жаловаться ежедневно
---
Проверить факт включения rcsi для базы можно и проще. Открыть в ssms свойства базы и в параметрах найти
Is read commited snapshot on
Если Истина - все норм.
Если ложь и у вас база в режиме совместимости 8.2.13 и ниже либо платформа 8.2 - можно тут же поставить Истина. Блокировок станет меньше.

Кстати сам по себе этот режим при первой установке замедлит работу в базе. Не сильно но на несколько процентов - десятков процентов. Это продлиться до первой реструктуризации индексов. Надеюсь она у вас еженедельная?
Впрочем если вы прошаренный спец по настройке скуля под 1с и у вас FillFactor под индексы стоит не ноль - вас и это замедление не коснется.

Зы. Не утихают споры - является ли установка rcsi нарушением лицензионного соглашения с 1С.
---
Нет совершенно точно проверял и пересоздавал базу на сервере. Вы не правы, автоматически не устанавливается. То есть как минимум есть одна ситуация когда это не так.
---
И совершенно точно автоматически ну устанавливается правильная настройка баз вплоть до версии 8.3.13. По крайней мере на одном сервере на моей работе, а значит у миллиона пользователей есть такие же проблемы. Четко перепроверил. Так что не бойтесь сомневаться в вашей "абсолютной уверенности".
---
Еще есть такая вещь как статистика MS SQL Server

Когда MS SQL Server нарабатывает статистику, он начинает правильно связывать запросы.

Не буду приводить запросы, которые упрощает MS SQL Server, но конкретно повышается скорость.

Вообще статистика запросов MS SQL Server - практически искусственный интеллект.

Не думаю, что в вашем случае стоит ждать накопления статистики, но вдруг...

Попробуйте запустить План выполне́ния запро́са на обоих серверах и посмотрите на разницу.
---
Об индексировании тоже подумал - запустил несколько часов назад. Скоро должно завершиться (база большая).
Другие отчеты отрабатывали получше, без таких серьезных заминок. Сейчас не с чем сравнить, так как все еще идет ТИИ и база занята.
---
Всем спасибо за информацию. Проблема решилась после нескольких процедур, а именно:
1. Тестирование и исправление с реиндексацией таблиц и пересчетом итогов.
2. Настройка взаимодействия 1С и SQL через Shared Memory - без сети через участок памяти. Видимо, не все идеально было при передаче по сети.
3. Прочие нюансы, которые настраивал системный администратор со стороны нового сервера. Всего что он менял не знаю. Были какие-то нюансы с размером блока диска с базой и т.д.

Теперь тот же отчет строится не 23 секунды, а 4. Как-то так...