v8: Планировщик заданий вешает базу. #569929

Добрый день. Помогите разобраться со следующей проблемой. Платформа 1С:Предприятие 8.2 (8.2.13.202) Конфигурация Агент+. Управление торговлей, редакция 10.3 (10.3.13.2) Win 2008 R2 x64 MS SQL Server 2008 R2 x64 Сервер 1с настроен на 3 рабочих процесса. Размер базы выгруженной в файловый вариант 13Гб до 40 пользователей одновременно База на сервере одна. Галочка Блокировка регламентных заданий в свойствах базы включена. При просмотре соеденений в консле сервера постоянно видно 3 планировшика без подключения к какой либо базе. Время от времени появляеться ещё 3  планировшика с подключением к базе. В этот момент невизможно проводить документы у пользователей сообщение об ошибке: Конфликт блокировок при выполнении транзакции: Microsoft OLE DB Provider for SQL Server: Превышено время ожидания запроса на блокировку. SQL Profiler эти блокировки не регистрирует. В технологическом журнале сообщения следующего содержания: 55:30.3370-2,SCALL,3,process=rphost,p:processName=ServerJobExecutorContext,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,ClientID=1,Interface=0459eaa0-589f-4a6d-9eed-c1a7461c8e3f,Method=4 55:30.3373-1,DBMSSQL,3,process=rphost,p:processName=utb,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,Trans=0,dbpid=,Sql=SET LOCK_TIMEOUT 20000 55:30.3375-1,DBMSSQL,3,process=rphost,p:processName=utb,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,Trans=0,dbpid=,Sql=SET DATEFIRST 1 55:30.3377-1,DBMSSQL,3,process=rphost,p:processName=utb,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,Trans=0,dbpid=,Sql=SET ANSI_PADDING ON 55:30.3379-1,DBMSSQL,3,process=rphost,p:processName=utb,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,Trans=0,dbpid=,Sql=SET XACT_ABORT ON 55:30.3386-2,DBMSSQL,3,process=rphost,p:processName=utb,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,Trans=0,dbpid=58,Sql=select count(*) from _YearOffset,Rows=1 55:30.3389-2,DBMSSQL,3,process=rphost,p:processName=utb,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,Trans=0,dbpid=58,Sql=select Offset from _YearOffset,Rows=1,RowsAffected=-1 55:30.3511-121,DBMSSQL,3,process=rphost,p:processName=utb,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,Trans=0,dbpid=58,Sql="SELECT spid, blocked FROM master..sysprocesses WHERE blocked > 0 AND lastwaittype LIKE 'LCK_%'",Rows=0,RowsAffected=0

Извиняюсь что некрасиво оформлено. Ткните носом в ФАК по оформлению. Добавлю скрины.

я бы для начала оставил 1 процесс, нафига вам 3 на 64 битном сервере с 40 пользаками? 1 рабочий+1резеврный оптимальный вариант.

ну и платформу до 219 обновить

Проблема не давала о себе знать 4 дня. Сегодня опять появляется 3 дополнительных планировщика с подключением к базе, "Превышено время ожидания запроса на блокировку" или невозможно получить доступ к объекту, ничего не проводиться и даже в справочники записать нельзя. Мониторинг список сеансов на предмет блокировок не выявил ничего криминального, только одна блокировка у пользователя который запустил 2 сеанса одновременно. Перевод на новую платформу запланирован на 22-е.

процессы значит не убрали, почему? рестарт службы агента сервера ночью делается?

что-то похожее было. Из-за проблем с электричеством сервак вырубился. После этого, в Журнале регистрации - планировщик заданий запускается, но не завершается, и так каждые 5 минут. + сеансы пользователей тоже рвались. Вылечили переустановкой сервера 1с

Обновил платформу до 219, оставил 1н рабочий процесс. Проблема повторяеться. Как водиться искал не там где нужно и не то что нужно. SQL Profiler смотрел как раз на взаимные блокировки, их небыло. А нужно было мониторить на долгие запросы. Есть запрос на провидение по партиям который очень долго выполняется если  документ проводиться задним числом. При попытки провести другие документы, запускается дополнительный планировщик с подключением к базе, проведение завешались неудачей «Конфликт блокировок» и планировщик исчезал. Т.к. попытки проведения были постоянными, планировщик висел постоянно и я принял его за виновника всех моих бед. Для меня так и осталось непонятным, зачем он собственно запускается. Ниже сам запрос, план выполнения и пр. Буду очень благодарен если подскажите как подкрутить индексы для ускорения работы.

[URL= запрос [URL=

Переписал запрос по рекомендациям на , подзапросы  вынес во временные таблицы. Заметно уменьшилось время выполнения (2~3 раза быстрее). Отложить восстановление последовательности на ночь нельзя, т.к. предприятие работает круглосуточно и львиная доля документов вводиться при ночной отгрузке. Есть только 2е субботы в месяц, за которые с горем пополам пытаемся восстановить движение по партиям. Проблема не решена.

вообще там в типовых беспредел с этими регламентными заданиями. Например, в БП 2.0 есть регламентное задание "ПересчетИтоговРегистровНакопленияБухгалтерии". Если посмотреть у него в расписании, то там написано - делать 5-го числа каждого месяца один раз в час. И вчера как раз было 5-е число месяца. Бухгалтерия полдня на ушах стояла, пока не разобрались в чем дело. В общем, надо брать калаш и ехать на Селезневку разбираться.

Убрал галочку "Блокировка регламентных заданий" в свойствах базы. Выполнил регламентное задание "Пересчет итогов регистров накопления" на 30.09.2011г. У пользователь при попытке проведения выходило сообщение о блокировке. Задание выполнялось меньше 15мин. Субъективно стало лучше. Запрос "по партиям" стал выводить меньше записей, 1-3 вместо 10-15(это нормально?). Объективно оценить прирост производительности пока не могу.

бред процессов должно быть мин(КоличествоКамней-1, КоличествоОдновременыхСеансов) при 40 пользователей нужно ставить колличество камней - 1

+ разумеется если памяти хватает

Может всё таки ядер? Где то читала рекомендацию по процессу на 12-15 пользователей. Исходя из этого и делал 3 раб.процесса. При уменьшении с 3х до 1го процесса разница особой не увидел. Следует иметь ввиду что на этой же машине работает и MS SQL Server. По мониторю пару дней после перерасчёта итогов и поставлю 4 процесса (ядер 8). Ткните носом в обработку фонового восстановления последовательности для УТ.