Регистр сведений. Одно измерение, 2 ресурса. Простой запрос на выборку измерений с условием по 1 из ресурсов. Индексов по ресурсам нет. В профайлере запрос в sql выполняется влет, несколько миллисекунд. Результат на клиенте я получаю через несколько минут. Хотя еще вчера я и на клиенте получал результат через несколько секунд.

Сервер 1с, а вместе с ним и бд - перезагружали. Выгрузка-загрузка - слишком долгий вариант для несколько сот гигабайтной базы. Что еще можно сделать?

Сеть?

(0) Мало информации. Возможно "еще вчера" у тебя не было данных. А сегодня их - вагон и маленькая тележка.

(2) Админы говорят, что ок
(3) Там и вчера и сегодня овер 1кк записей в этом РС. Смысл в том, что сегодня на sql запрос выполняется влет. А вот результат до клиента едет крайне долго. Тут проблема не в этом запросе, его просто было проще всего в профайлере отловить. Вообще все жутко тормозит с утра.

(4) Проверить локально на сервере "админы говорят"

Проверить толстый и тонкий клиент

(4) Проверить загрузку сети на сервере, загрузку диска на сервере и загрузку процессора.

(7) все в пределах нормы. т.е. около 0%

Ммм... Лимон записей на клиента тянуть?

В итоге, какую проблему нужно решить: "Вообще все жутко тормозит с утра."  или "Результат на клиенте я получаю через несколько минут." ?

(9) это условие в запросе. я просто на нем тестировал перфоманс)
(10) мне кажется это связанные вещи. все тормозит, один из запросов, больших, выполняется по полчаса, вместо нескольких секунд. у него в условии сабжевый подзапросик простенький. начал его анализировать.

(9) так как условие НЕ В (искомая выборка). Чтобы на клиенте получить из миллиона - несколько штук.

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

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

запустили локально этот запрос. так же несколько минут выполнялся. в течении этого времени сеть выше 10% не прыгала, CPU - ядро где rphost крутится всегда около 15-20%, с редкими скачками до 60%. очередь к диску - 0.01-0.02.

Сервер монструзный. База на террабайтном SSD. Памяти 128gb. Так что сервер точно не причем)

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

А если перезапустить процесс сервера 1С?

чтобы проверить торможение сети или сервера скуля замени все данные на Количество(*)
на сервере точно такой же запрос выполнится (условно), а на клиента всего 1 число полетит

(17) Выбиралась ссылка, угадал. Заменил на представление - стало пошустрее, около минуты.
(18) Весь сервер перезагружали.
(19) так миллисекунды

может представления данных вытягиваются так долго?

(20) Вы через типовую консоль делаете? Она вообще дико тормозная под УФ при больших объемах, я от нее из-за этого отказался.
(21) Кстати да, в модуле же теперь можно свое представление формировать, поди вчера добавили и забыли.

[пальцем в небо] попробуйте на sql статистики обновить

В консоли помести результат в ВТ и выполни без временных таблиц, посмотри скорость.

Проверьте сеть, выполнив команду ping с указанием большого размера отправляемого пакета. Параметр -l 65000. 1С-ка обменивается пакетами нестандартно большого размера. Бывает, что при обычных проверках сети проблем не возникает, а большие пакеты теряются.

(20) Вероятнее всего с запросом всё нормально. И с сервером тоже всё номально. Проблема в процессе проверки запроса.

Сегодня словил плюху, типовой, тупейший запрос по распределению взаиморасчетов по документам, уходил в бесконечность, генерируя 100 загрузку ядра и блокировку всех, кто хочет провести распределить расчеты взаиморасчетов (а это печать ТОРГ12, там чето на авансах завязано).
В итоге, у меня все было забито runnable потоками, SOS_SCHEDULER_YIELD ожиданиями, клиент выяснил, что SQL пользует только 4 ядра из 16 щедро для него отведенных, ибо Standart Edition, а я получил немного
https://lurkmore.co/SCP

И че, и так и не победил. Ребилд индексов, обновление статистики, очистка процедурного кеша, checkdb таблиц, ничего.
Переписал запрос на 2 пакетных запроса и заработала.

Хрен знает.
Причем Query Compiled план все нормально показывал, а фактический план я, конечно, так и не дождался.

(27) У меня такое один раз было, когда шёл запрос к плану счетов, а субконты не ВЫРАжались. За один месяцу нормально, за другой - полчаса...

*овнокод в обработке получения представления - такое бывает. Например, получение значений через точку от ссылки.
А платформа на это дело ставит неявную блокировку.

(0) если "вчера работало,а сегодня нет" и "быстро в sql, но медленно в 1с" - получается проблема в 1с.
Перезагружать вы её уже перезагружали. Почистить scntx попробовать...