Добрый день.
Помогите разобраться со следующей проблемой.

Платформа 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: Превышено время ожидания запроса на блокировку.
HRESULT=80040E31, SQLSrvr: SQLSTATE=HYT00, state=38, Severity=10, native=1222, line=1

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.3381-1,DBMSSQL,3,process=rphost,p:processName=utb,t:clientID=32,t:applicationName=JobScheduler,t:computerName=SERVER-2010,Trans=0,dbpid=,Sql=SELECT @@SPID
55:30.3383-1,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 sysobjects where name='_YearOffset'",Rows=1
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=http://fastpic.ru/view/27/2011/0925/ad28298b0f6cf64c4ee1fe2ca83a4e69.png.html][IMG]http://i27.fastpic.ru/thumb/2011/0925/69/ad28298b0f6cf64c4ee1fe2ca83a4e69.jpeg[/IMG][/URL]

запрос http://pastebin.com/tk6QCHQh

[URL=http://fastpic.ru/view/32/2011/0925/ac6c983ac0c3597ec64f4d98b0ce79de.png.html][IMG]http://i32.fastpic.ru/thumb/2011/0925/de/ac6c983ac0c3597ec64f4d98b0ce79de.jpeg[/IMG][/URL]

Переписал запрос по рекомендациям на http://kb.1c.ru/articleView.jsp?id=44, подзапросы  вынес во временные таблицы. Заметно уменьшилось время выполнения (2~3 раза быстрее).

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

Проблема не решена.

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

Убрал галочку "Блокировка регламентных заданий" в свойствах базы.
Выполнил регламентное задание "Пересчет итогов регистров накопления" на 30.09.2011г.
У пользователь при попытке проведения выходило сообщение о блокировке.
Задание выполнялось меньше 15мин.

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

(2) бред

процессов должно быть

мин(КоличествоКамней-1, КоличествоОдновременыхСеансов)

при 40 пользователей нужно ставить колличество камней - 1

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

(12) Может всё таки ядер?
Где то читала рекомендацию по процессу на 12-15 пользователей. Исходя из этого и делал 3 раб.процесса.

При уменьшении с 3х до 1го процесса разница особой не увидел.

Следует иметь ввиду что на этой же машине работает и MS SQL Server. По мониторю пару дней после перерасчёта итогов и поставлю 4 процесса (ядер 8).

Ткните носом в обработку фонового восстановления последовательности для УТ.