А не связано ли это с режимом разделяемых итогов?

WalkaboutНе думаю, без них в принципе сложно что либо параллельно записывать в базу. Поэтому при сильно большой пользовательской нагрузке он как бы по умолчанию уже включен Без них, это без кого?

WalkaboutЕще как оказалось в 8.2.15 количество проводок, которое при записи в транзакции укрупняет блокировку нужно считать с учетом удаляемых в этой же транзакции записей. Т.е. Если перепроводится документ в котором например до перепроведения уже было 6000 проводок, то при записи 4000 новых в процессе проведения, даже если записи дописываются частями, регистр полностью заблокируется. Т.е. Считается суммарное количество ключей блокировки в одной транзакции на менеджере блокировок Что-ли или у меня утро не доброе или... не пойму я о чем вы.

"записи дописываются частями" - ?

"Считается суммарное количество ключей блокировки в одной транзакции на менеджере блокировок" - о каком менеджере блокировок идет речь: о том, что работает в MS SQL(тогда, это вопрос эскалации блокировок) или о том, что в сервере приложений(он такое умеет, где прочли?).

"Еще как оказалось в 8.2.15 количество проводок, которое при записи в транзакции укрупняет блокировку нужно считать с учетом удаляемых в этой же транзакции записей. "
Это не в 8.2.15 а в самом ядре MS SQL. Опять же, это эскалация блокировок. На это 1С никак не может повлиять, это определяется самим MS SQL Server`ом. Зависит от многих причин - индексов, расмазанности данных по страницам... объема данных.


В документации (к MS SQL) механизм эскалации описан "не прозрачно". Где-то говорится о том, что эскалация с записи до страницы происходит при 5 000 блокировок, где-о говорится, что не 5 тыс. а больше... где-то, говорится, что эскалация сразу со страницы поднимается на таблицу...
Так же, эскалация будет тогда, когда заканчивается буфер для блокировок. Тогда будет эскалация до таблицы.
Это ситуации, когда уровень блокировки может повышаться в процессе выполнения запроса. Не транзакции, а запроса.
Ну и естественно, многое зависит от того, как MS SQL сформирует план выполнения запроса - это определяет уровень изоляции до выполнения запроса.
В принципе, можно запретить повышать уровень блокировки при эскалации(через флаги трассировки) но сама MS этого очень не рекомендует делать, т.к. в таком случае высока вероятность постоянных дэдлоков.



P.S.
Для того, что бы эта тема не превратилась в ПТ, нужно описывать конфигурацию вашего SQL сервера и базы данных в нем (режим востановления базы данных, наличие планов обслуживания, состояние данных в MS SQL на момент опытов... )

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

Как сконфигурирована база 1С, включен ли полнотекстный поиск, RLS, версионирование...

Было бы не плохо описать что происходит при работе с клиента и с сервера. Что бы понимать влияние канала связи...


А так, это сравнение сферичеких баз в вакууме.

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

Ну да.. ну да... только вот, наверное, читать нужно было между строк и с ХШ...
Удачи в изысканиях.

P.S.
Прежде чем говорить кому-то, что стоит внимательно читать, может самому стоит последовать своему же совету , а ;)