Добрый день.
Есть самописка, 150+ пользователей, MS SQL.
Периодами тормозит 1С, по 5 минут может быть каждые 2 часа, или как то так. То есть не постоянно, а кратковременно. Под тормозами понимается например формирование печатной формы, обновление данных на сложной форме, в обычное время 1-2 сек, в период торможения 10 секунд, примерно так. Сисадмин проверял сервер, говорит, что ресурсов хватает, затыка нет в его части.
К сожалению, опыта нет выявления причин таких проблем, возможно какой-то пользователь выполняет тяжелый отчет или что-то подобное.
Подскажите, какие есть инструменты для анализа? Или может подскажите в какую сторону копать.

(0) Технологический журнал

Какие его, админа, доказательства кроме слов?

1.У сиквела в настройках max degree of parallelism >0 ?
2.сам посмотри про "ресурсов хватает".
3.какие-то функции твои сервера/сервер помимо 1С и СУБД выполняют? Ничего по расписанию на сервера не запускается (не имеющего отношение к 1С)?
4.Какие-то изменения в момент тормозов в консольки кластера 1С по РП видны?

(3)
1. Стоит ноль, кажись по умолчанию, не меняли, почитал, рекомендуют единичку, поставлю.
2. В момент торможения, по типовому монитору ресурсов нет никаких зашкаливаний ни в процессоре, ни в памяти, ни в дисках
3. Резервное копирование средствами SQL, но по времени не пересекается с торможениями.
4. На какие параметры обратить внимание?

может в 1с какое то регламентное запускается?

(4) А в самой СУБД точно только одна база? И на какой платформе это вся картина наблюдается?

(5) или rphost новый создается и всех туда кидает

(7) вполне, мы как то мучались пару дней пока перезапуски не заметили.

Видимо периодически выполняется запрос, занимающий все потоки. Попробуй этим отчетом http://devtool1c.ucoz.ru/index/statistika_po_zaprosam_mssql/0-58 посмотреть самые высоконагружающие SQL сервер запросы. Обрати внимание на parallel ratio и cpu time.

Конечно может быть и по очереди к диску затык - сканирование какой то большой таблицы. С большой вероятностью в отчете (9) ты это увидишь.

(6) Есть еще одна рабочая, но там 3 пользователя, больничная аптека 2. Платформа 8.3.13.1644
(7) Понаблюдаю, у нас сейчас 2 рабочих процесса.

Если период медленной реакции длится 5 минут, то врядли это перезапуск rphost. Для него обычно 10-20 секунд хватает, тем более если сеансы есть только в одной базе.

А совет (1) уже включил или не знаешь что это?

по времени и периодичности похоже на перестроение какого-нибудь индекса.

(13) посмотрел, не делал ранее, попробую, просто не быстро

(0) >Периодами тормозит 1С, по 5 минут может быть каждые 2 часа

перезапуск сеанса rphost

(16)+ делается чтобы почистить утекшую рамку и т.д.
если отрубить будет после двух часов тормозить опупенно все время а не 5 минут

(12) там 150 юзеров пока кэш прогреет

Диспетчер задач в виндовс, производительност, 1с-регламентные -фоновые задания.

(19) чтоб были регламентные - они там должны быть написаны. Сказано было, что это самописка. Поэтому предполагать подобное можно, но об этом должен знать ТС, а не мы здесь.

(11) // Платформа 8.3.13.1644 и два рпхоста. и вторая база типовая.

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

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

Если бы была названа платформа 8.3.17, то такого совета я бы давать не стал, т.к. это не имело бы практического смысла.

типовая и нетиповая явным образом мешают друг другу. Их нужно друг от друга изолировать.

Во сейчас снова тормозит, подскажите вот один сеанс сильно выбивается от всех, это может быть связано https://ibb.co/GWqBKXr

(23) настраивай тех журнал
то, что какой то пользователь выбрал в 4 раза больше данных вообще ни о чем

(23) так ты же даже названия баз затер - как можно видеть, что этот пользователь мешает какой-то базе, если не видно в одной он базе вместе с остальными или в разных.

(25) это все одна база

По чтению там за 5 минут считано всего лишь 25, а среднее чтение за 5 минут около 14 - относительно этого нет оснований для выводов.

И время, что на запись отправлено в 4 раза больше - так это за все время жизни сеанса, а может там несколько дней он не отключался.

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

Кстати, не удивлюсь, если окажется, что в периоды торможения базы нагрузка будет ниже. Потому что показатель будет зависеть от наличия тормозов, а не наоборот.
Наличие блокировок нужно ещё посмотреть. Очень может быть, что они [блокировки] будут создавать тормоза и резать вообще все показатели производительности.