Стали тормозить два клиента

Если имеется станция на ХР, то судя по всему ей сто лет в обед? Никакой сервер не спасет, если рабочая станция слабая. Это из явного. Из неявного - анализируйте список регламентных заданий. Вполне вероятно корень зла там находится.

Может в это время по сети что-то летит большое и тяжелое с этих/на эти рабочих мест, у одного моего пользователя было 2 ПЭВМ с перекрестным резервным копированием через robocopy, в 15-00 с одной ПК1 на ПК2, в 16-00 с ПК2 на ПК1. Работать было практически невозможно, дешевый коммутатор и проч.

Настройте технологический журнал на сервере 1С и посмотрите что такого делал сервер во время тормозов.

Может антивирус проверку запускает, или дефрагментация запускается, или процессор перегревается ввиду того, что в это время ветерок в ноги на полную включают. Можно ещё погадать.

В общем - поменяю системные блоки.
И надо подумать над доступом по RDP.

Не пойму.
Куда то пропал мой вчерашний последний пост.
Да и группировка сообщений в теме какая то странная.

Ну да ладно. Дублирую вчерашнюю информацию.
Вчера нарвался на сильные тормоза.
Проблемные рабочее места чуть ли не впали в ступор.
Даже нажатие на экранные кнопки отрабатывались секунд по 20.
Скорее у девушек запустил RDP.
На сервере - аналогично. Сервер стоит колом.
Стал искать гада. Все чисто.
Надоумило меня заглянуть в регламентные задания.
А там в это время происходило обновление индекса полнотекствого поиска.
Не буду говорить что я сделал - не суть важно.

Сегодня ругается зарплатник. Зарплату клинит не по детски.
А у него стоит ЗУП 3.1 под SQL (базы стоят на том же самом сервере) и платформа та же самая (8.3.10.2667)
Памятуя вчерашние события полез смотреть регламентые/ фоновые задания.
И то же самое. Обновление индекса ППД.

Вопрос.
С какой стати эта "легкая" и быстрая операция стала ставить сервер на дыбы?
До середины лета все было нормально а потом УПП и ЗУП стали очень нервно относится к обновлению индекса.

p.s. я конечно обновление и слияние индекса после этого сделал раз в сутки, но ведь это не порядок. Надо как то лечить таблетками, а не отрубать голову топором.

Все же, похоже я нашел причину тормозов.
Допускаю, что обновление индекса могло приводить к тормозам, но это был вторичный симптом.
Виновником оказался tempdb.

Только вот если у людей он бывает растет неумеренно - у меня наоборот - не растет. Дискового пространства - выше крыши, а размер этой базы не превышает 1,9 Гб.
Допускаю, что не растет потому что нет необходимости. Но тогда получается, что tempdb забивается хламом, который как то тормозит работу и почему то не чистится.

В общем - запускаю шринк tempdb и тормоза сразу пропадают.

Никто с такой проблемой не сталкивался?
Не подскажете лекарство?
А то шринк, конечно выход. Поставил его в регламентое задание SQL и все ОК.
Вот только иногда на 1С запускаються операции требующие очень, очень много времени.
Например закрытие месяца, перепроведение документов и пр. И эти операции обязательно попадут под шринк.
И что тогда будет? Задание 1С встанет? Или получим не корректные данные?
В общем то, не хотелось бы прибегать к столь кардинальным мерам, как обрезка временной базы.

p.s. есть небольшая надежда, что поможет SP2 для SQL. Но информация весьма смутная и не факт, что достоверная.

И опять мимо кассы!!!
Главный виновник не tempdb.

В пять часов вечера звонок.
Все встало.
Захожу по RDP на сервер.
Постоянная загрузка процессора 50% - что для нас не реальная цифра.
Пробую шринк tempdb. Не помогает. Смотрю регламентные задания - ничего не выполняется.
Смотрю в консоли сервера 1С.
А там у один из клиентов перемолотил объем данных свыше 50 ГБ. Цифра не реально большая. Более чем на порядок выше значения когда все работает без сбоев.
(Этот клиент производит массовую обработку документов и на основе одних (заказ покупателя) - формирует другие документы (накладные сч/фак, пропуска). Но в нормальных условиях такая операция не приводит к каким либо затыкам.
Удалил клиента из консоли сервера - загрузка упала до нуля.

В общем - нет никаких мыслей - куда дальше копать.

Такое впечатление, как будто слетает фильтр и sql начинает рыться в документах без временнЫх ограничений или вообще шарится во всех существующих документах.

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

Я сейчас поговорил с человеком, который обновляет нас.
Он сказал, что у нас нет динамических списков.
У нас конфигурация не на управляемых формах.

Во вложении файл результатов.
Как видно - стало плохо в районе 13.43-13.44. Потом я вышиб пользователя/процесс в консоли управления сервером 1С
Потом в районе 13.45 пользователь (Бурова) опять зашла в программу и доделала пропуска уже без тормозов.

Обратите внимание.
Если обычно идет чередующаяся последовательность Context SDBL, то когда стало плохо - пошли сплошные SDBL.

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

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

Возможно, моя информация из технологического журнала не полная?
Что тогда надо добавить в logcfg.xml?

В воскресенье тоже были тормоза в 10.19
Работница перезагрузила свой компьютер и все заработало без заминок.
Вот что в этот раз увидел в технологическом журнале:
Два EXCP события
19:14.971000-0,EXCP,0,process=rphost,OSThread=70912,Exception=NetDataExchangeException,Descr='Ping time out expired on direction: directionID=143f9ef9-73d6-405d-bc76-5b225eebdfe8, lastActivity=937164379, lastActivityTestTs=(937216270,937217286,937218301,937219317,937220332,937221348,937222364,937223379), timeout=60000, period=12000, currentTS=937224395, nChecks=3'

19:15.283000-0,EXCP,0,process=rphost,OSThread=72744,ClientID=193,Exception=NetDataExchangeException,Descr=Ping time out expired on connection

Речь идет о подключении рабочей станции к серверу? Была нарушена связь?
Или это что то другое?

Подозреваю, что все же нашел.
Задал в тех. журнале - фиксировать все, что превышает заданный интервал времени.
Журнал во вложении.
И во время тормозов зафиксировал несколько SESN событий с ненормально большим временем исполнения.

38:59.382005-18394821005,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,p:processName=DebugQueryTargets,OSThread=64728,t:clientID=1745,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=zup3,Appl=1CV8C,Nmb=1,ID=69620513-ee71-41bb-ada9-703eeaa1b5eb
39:01.835005-145328979990,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=70648,t:clientID=968,t:applicationName=ServerProcess,t:computerName=server,Func=Attach,IB=MILK,Appl=1CV8,Nmb=44,ID=90f78d0d-7d8a-4210-9f5d-d1d8dc45f9ac
39:01.835006-145328979993,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=70648,t:clientID=968,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=MILK,Appl=1CV8,Nmb=44,ID=90f78d0d-7d8a-4210-9f5d-d1d8dc45f9ac
43:15.232019-27458392013,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=71512,t:clientID=1658,t:applicationName=ServerProcess,t:computerName=server,Func=Attach,IB=milk,Appl=1CV8,Nmb=59,ID=b256391a-6542-4269-825b-2d3331e54200
43:15.232020-27458392016,SESN,0,process=rmngr,p:processName=RegMngrCntxt,p:processName=ServerJobExecutorContext,OSThread=71512,t:clientID=1658,t:applicationName=ServerProcess,t:computerName=server,Func=Finish,IB=milk,Appl=1CV8,Nmb=59,ID=b256391a-6542-4269-825b-2d3331e54200
43:21.232010-188010,CONN,0,process=rmngr,OSThread=69300,t:clientID=1896,t:clientID=1896,t:computerName=exp2,t:applicationName=1CV8,t:connectID=0,Calls=6

Как бы это расшифровать. Или что еще надо в файле настроек, чтобы можно было понять - что это?

Чего криминального может быть в фрагменте лога транзакция из вложения для пользователя Титова Надежда?
Время между 15.39 и 15.44

Я не уверен, что поступаю правильно, но решил закрыть эту тему и создать новую.
Здесь я несколько намусорил

видимо продолжение в https://forum.infostart.ru/forum34/topic204178/