Описание проблемы: периодически, примерно раз в день, как правило утром или вечером, на tempdb рабочей базы резко возрастает нагрузка на несколько часов.
Скрин заббикса https://disk.yandex.ru/i/DCGoeKb3m1HgXw

Конфигурация самописная на базе старой БП. 1С 8.2 ОФ. SQL 2008. Юзеров много.

Что проверял:
смотрел консоль сервера 1С - долгих соединений нет
задания в самом SQL - ничего не запущено
очередных переносов итогов по регистрам в этот момент нет (да и не идут они так долго)
техножурнал - не показывает тяжелых запросов, есть долгие, но в пределах обычной работы. Опять же, если б что-то висело долго - соединение было бы видно в консоли 1С.

Способом из https://its.1c.ru/db/metod8dev/content/5813/hdoc
смотрел "Запросы, создающие нагрузку на диск":
Там выдаются запросы, но разные.
1) просто просмотр списка журнала реализаций (top 28 from _DocumentJournal7838). Этот же запрос выдаётся в тенхожурнале, но явно не он причина такой нагрузки, похоже на глюк статистики
2) запрос к бухрегистрам, это уже интереснее, т.к. там хотя бы временные таблицы задействованы:
INSERT INTO #tt1024 (_RecorderTRef, _RecorderRRef, _LineNo) SELECT
T1.RecorderTRef,
T1.RecorderRRef,
T1.LineNo_
FROM (SELECT DISTINCT
T2._RecorderTRef AS RecorderTRef,
T2._RecorderRRef AS RecorderRRef,
T2._LineNo AS LineNo_
FROM _AccRg10321
....

Пока не могу конкретно этот отчет найти в 1С. Похоже на какой-то типовой бух.отчет, т.к. идет отбор по ИНН (и соединение с таблицами Организации, Контрагенты, Физ.лица)

Но опять же - нет висящих долгих соединений в 1С.

Как найти вредителя? Может кто сталкивался с подобным?

Регзадания отключать не пробовал?

(1) У нас их не так много и нет каких-то особенных. Можно будет попробовать, чтобы железно их исключить.

(1) +100 и заодно запретить работу пользователям.
Это точно должно помочь! и никаких нагрузок на tempdb!
Удобно ведь.

(3) Хватит пенетрировать. Это первое при временных непонятных нагрузка.

(0) >> ...просмотр списка журнала реализаций (top 28 from _DocumentJournal7838). ... но явно не он причина такой нагрузки

Откуда вывод о том, что не он причина нагрузки?
Формы списков документов в УФ дают пользователям широчайшее поле для манипуляций с настройками, отборами, группировками.

Встречаются особо талантливые пользователи, способные настройками журнала подвесить базу.
Делаем отбор по какому-нибудь реквизиту реквизита табличной части, имеющему большой составной тип (например, характеристика плана видов характеристик ВидыСубконтоХозрасчетные), и привет семье...
Например, Реализация.Услуги.Субконто2.Номер Содержит "123".
Ну и делаем в списке группировку, например, по реквизиту "Покупатель" (контрагент).

(4) В 99% случаев это тыканье пальцем в небо.
С регламентными заданиями, как правило, и так сразу видно и понятно - какое именно задание создаёт нагрузку.

(0) https://www.sqlservercentral.com/scripts/tempdb-usage-per-active-session

(5) У нас ОФ (в описании проблемы указано). Плюс tempdb это  не трогает, и эти запросы всего по 20 секунд выполняются в случае, когда слетает статистика.

Готовится закрытие года.
Вы уверены, что дело не в банальном запуске главбухом (или кем-то из бухгалтеров) перепроведения всех документов или больших пакетов документов?
Это может занимать часы, запускается хаотично (не по регламенту).

(9) Массового перепроведения документов у нас нет. У нас и без того непрерывное проведение (30 тыс накладных в сутки).
И это не дало бы такую резкую нагрузку на запись в tempdb.

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

++