Не работают управляемые блокировки 1С #626282

Есть конфигурация УПП 1.2.22.4 на платформе 8.1.15.14. Веду работы по оптимизации производительности. Поставил в свойствах конфигурации Режим управления блокировкой данных = Управляемый. Внес в функцию ОбщегоНазначения.ПолучитьЗначениеПеременной изменения Это, чтобы даже управляемые блокировки не ставились. Т.е. при таком подходе блокировок быть вообще не должно (если работа идет с разными записями таблиц базы данных). Делаю следующее: под отладчиком запускаю один сеанс, ставлю точку останова в модуле объекта реализации товаров и услуг в процедуре ДвиженияПоРегиструСписанныеТовары после строки Движения.СписанныеТовары.Записать(Истина); провожу реализацию, движения по списанным товарам записываются и транзакция остается подвешенной (на точке останова), запускаю второй сеанс, провожу другую реализацию и она зависает на блокировке. Если точку остановка поставить на строке записи движений (т.е. чтобы транзакция останавливалась до команды записи), то все нормально. Это значит, что блокировка происходит именно на таблице СписанныеТовары. Выгрузил этот cf, создал пустую базу, зарузил этот cf, создал 2 реализации. Проделываю то же самое, блокировок нет (как и должно быть). Сравнивал по профайлеру планы выполнения запроса - полностью совпадают (кое-где различаются % времени выполнения отдельных команд в плане, но это и понятно, объем данных разный, но сами команды планов полностью идентичны). С базой все регламентные операции делал (переиндексация, обновление статистик, очистка процедурного кэша). Почему происходит блокировка?

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

программно надо прописывать (используя объект Новый БлокировкаДанных), только для того, чтобы не нарушилась логика работы конфигурации, т.е. остатки не ушли в минус. И только.

и ты веришь что в УПП 1.2 все уже было прописано под них?

Вам видней. Но как платформа поймёт какую блокировку ставить если ей явно не указать?

в 1.3 то не везде прописано ЕМНИП

в УПП 1.2.22.4 не все прописано, но меня это пока не интересует. Допишу в моем случае как раз платформа и не должна ничего ставить (ну почти ничего, есть все равно неявные блокировки журналов при записи док-тов и т.д.). А sql сервер при управляемом режиме использует уровень блокировок Read Commited, а не Serializable, т.е. блокировка записей, а не диапазонов вроде бы да, но переходит на УПП 1.3 мы не можем, слишком много дописок

[но переходит на УПП 1.3 мы не можем, слишком много дописок] лажа! это ответ неудачника

хорошо, отвечу корректней: на данный момент функционал из всей УПП используется очень ограниченный. В планах нет его расширять. Затраты на оптимизацию этого небольшого участка меньше, чем затраты на обновление на 1.3, т.к. дописок много. Структура и объем задач, стоящих перед отделом на данный момент не позволяют выделить время и внести это в план работ. Попрошу не обсуждать выбор этого решения, комментарий , и этот мой комментарий - это за рамками данного топика.

[А sql сервер при управляемом режиме использует уровень блокировок Read Commited, а не Serializable, т.е. блокировка записей, а не диапазонов]- ну ты ведь не создаещь объет БлокировкаДанных, а значит не указываешь какие именно диапазоны блокировать, поэтому блокируется весь регистр. По умолчанию видимо.

Не блокировка происходит, а конфликт блокировок

ЦУП поставь на базу будет понятнее что происходит

В анализе конфликтов особой сложностей нет. Главное аккуратно и не спеша разложить ситуацию и глянуть с помощью ЦУПа что происходит. В этих вещах - главное детали.

Неправильно, т.к. я не указал, что блокировать, то как раз ничего не должно блокироваться (кроме неявных блокировок платформой). Это предположение подтверждает и поведение на чистой копии (см. первый пост), где проходит все нормально выкладываю дословно, что пишет 1С Ошибка при выполнении обработчика - '{Документ.РеализацияТоваровУслуг(5734)}: Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки из-за ожидания сессии 3991' по причине: {Документ.РеализацияТоваровУслуг(5734)}: Ошибка при вызове метода контекста (Записать): Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки из-за ожидания сессии 3991 по причине: Конфликт блокировок при выполнении транзакции: Превышено максимальное время ожидания предоставления блокировки из-за ожидания сессии 3991 ЦУП, конечно, для анализа использовал сейчас выложу скрины ЦУПа, чтобы понятнее было

Сейчас ЦУПом что-то не получилось анализ сделать, ошибка в получении данных какя-то. Выкладываю прошлые замеры (там я обработкой перезапись набора записей Р.С. СписанныеТовары делал для возникновения блокировки), но суть та же

Одновременно проводишь документы с разными товарами/контрагентами? Если с разными - блокировки быть не должно. Если хотя бы у одного регистра совпадают измерения - будет блокировка, если в регистре не установлено "разрешить разделение итогов".

Думаю не совсем так. Блокировка происходит на Р.С. СписанныеТовары. Это периодический Р.С., подиченный регистратору с измерением НомерСтрокиДокумента, т.е. блокировка должна быть только если параллельно пытаются записаться наборы записей одной и той же реализации, а у меня реализации разные.

Можно ли где-то посмотреть детальные данные о текущих блокировках менеджера блокировок 1С? При моих действиях в сервер 1С Предприятие в ветке блокировки не отображает, что есть какие-то блокировки. Может тогда станет понятнее

что-то тема не нашла энтузиастов

Мало кто так глубоко залезает.

Да уж, сюда бы тяжелую артилерию вроде Гилева.

read committed <> отсутсвие блокировок

согласен. Это просто блокировка не диапазона записей (по индексу), а определенных записей. Однако, это не дает ответ на

Если ты работаешь в файловой версии - то управляемые блокировки не работают.

ты опять ничего не понял

если у тебя данные пишутся в транзакции - прочитать их пока транзакция не завершится - никак

а диапазон блокируемых записей может быть больше чем по PK

Конфликт управляемых блокировок можно обнаружить с помощью технологического журнала, событие TLOCK. Это на скуле, а управляемые, вроде, должны быть точные блокировки, пока 1С сервер не начнёт эскалацию.

версия клиент-серверная прочитать их можно, даже если они пишутся ALTER DATABASE MyDatabase SET ALLOW_SNAPSHOT_ISOLATION ON ALTER DATABASE MyDatabase SET READ_COMMITTED_SNAPSHOT ON

-> именно на скуле. записываемые данные не дает читать. читаемые данные дает читать.

это только на последнем скуле, не?

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

на 2005 заявлено, что работает. У меня 2005

может происходить эскалация в определенных обстоятельствах до страниц и даже до всей таблицы

. в скриншотах ЦУП уже все обнаружил . я не встречал информации, что сервер 1с умеет делать эскалацию. Эскалацию умеет делать СУБД при блокировке диапазонов записей, если план выполнения не удачный выбран

хм... .2 эскалацию делает скуль, когда думает, что заблокировать страницу/таблицу и выполнить транзакцию будет быстрее, чем заблокировать строку и выполнить транзакцию (условно)

справедливо опять же вроде только к блокировкам СУБД, а не сервера 1С предприятия. Из видно, что блокировка происходит именно менеджером блокировок 1с предприятия

По описанию это не SQL блокировка, а 1С. Что у них там внутри творится нигде не описано. но на 2005 использовать эту новинку не рекомендуется, по субъективным причинам. 1С умеет, на партнёрском недавно подтверждение встречал.

.2 допустим так. Но тогда бы 2 плана выполнения в моем тесте (с блокировкой на рабочей базе и без блокировок на чистой) имели бы разные команды (например scan table проскачило бы), а они одинаковые по командам

может идет блокировка по диапазонам/страницам и после перегрузки dtшки индексы попали на разные страницы, а в исходной базе были на одной...

.3 не берусь утверждать обратное, но определение оптимальности блокировки - сложнейший механизм. Не думаю, что 1с его реализовал, тем более что незачем. В атоматическом режиме это делает СУБД, в управляемом все отдается на откуп программисту.

там все сделано проще, в автоматическом идет repeatable read, в управляемом read committed + проверка на сервере того, что через блокировкаДанных установлена

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

и что? ты думаешь, это влияет на то, на каких страницах индексы находятся?

согласен, так что зафиксируем: сервер 1С эскалацию делать не может

не знаю как можно подтвердить или опровергнуть это. Можешь сказать? Просто я думаю, что если это так, то ms sql полная лажа - я очистил статистики и кэш, заново выполняю несколько десятков раз одну и ту же операцию, каждый раз происходит блокировка, а оптимизатор sql попрежнему продолжает блокировать страницы или даже таблицу, а не записи, хотя видит, что это плохо? сомневаюсь в этом, темт более ЦУП показывает, что мдкт не блокировка СУБД, а блокировка 1С, т.е. не sql виноват со своей эскалацией

побайтовым сравнением .mdf файла

не только, запись автоматически ставит, как управляемые, так и блокировки СУБД до конца транзакции.

я, наверное, неправильно формулирую... ты ничего нового по сравнению с тем, что сказал я - не сказал.

ну тесты я проводил не на одинаковых базах, а на рабочей и чистой с накатанным cf (не dt), так что не подходит

да, это как раз неявные блокировки. Но все-равно эскалации на сервере 1С не можеть быть имхо

тогда о чем речь? оптимизатор принимает решение на основании очень многих факторов, если бы у тебя две одинаковые базы вели себя по разному, тогда да... если у тебя чистая база, то возможно оптимизатор думает - ага, если заблокирую страницу, то это будет 100%данных и займет 15мс, а если построчно - то 50% и 17мс, а на грязной: 2% данных и 25 мс и 1% данных и 40мс... и делает какой-то свой вывод о том, что в первом случае лучше построчно, а во втором - постранично...

при чем тут сервер 1с? у тебя вылетает на ожидании потому что скуль блокирует по read committed.

думаю, мало кто скажет по каким алгоритмам работает оптимизатор. Но, он однозначно анализирует последствия своих решений (обратная связь), и он видит, что после таких решений на 20 сек происходит блокировка. Так что думаю это неверное предположение я смотрел коды ЦУП. Если режим упр. блокировками управляемый, то анализируются блокировки СУБД отдельно и отдельно блокировка менеджера блокировок сервера 1С. Почему тогда ЦУП показывает, что это блокировки 1с?

У нас где то была статья на тему исследования упр. блокировок.  Правда это было еще для 1С 8.1.  , хотя сомневаюсь что там что то принципиально поменялось.

Мне не верите, так прочтите у Гилёва Хотя это врядли относится к вашему случаю.

А к какому типу относится конфликт и как именно он происходит? Самое простое что может помочь - почистить РС списанные товары, он по сути особо не нужен.

Эскалации на сервере 1С не может быть - там возможны баги.Но это отдельный случай. Ведь если в документации про эскалации не написано а блокировки превышают множество допустимых - значит это баг платформы.

В некоторых случаях его можно просчитать, конечно понимая как концептуально вообще может работать "оптимизатор"(планировщик запросов).   Были случаи когда только план расчитывался более 5-и секунд.

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

Важно понимать некоторые основы. Например если локтаймаут sql стоит 10 секунд а ожидание блокировки(забыл как точно называется) на сервере приложений - 20. Значит дело в сервере приложения. Опять таки - есть трассировка которая однознаяно показывает события блокировок. Можно сравнить с ней.

кстати, там в картинках ЦУПа нарисовано, что блокировка по пересекающимся измерениям идет

там точно документы одинаковые? может надо через XML их перекинуть?

Форумлировка "система автоматически будет пытаться установить исключительные управляемые блокировки для модифицируемых данных" - очень расплывчатая.  Что значит "модифицируемые данные" ?

например НаборЗаписей.Записать

+ Почтайте в MSSQL на тему модифицируемых,читаемых, фантомных и т.д. и т.п. данных.  Есть множество вариантов. Если подобная логика реализована на уровен сервера приложений - она не может быть простой и однозначной. Существует несколько трактовок разрешений конфликтов.

у меня доступа к партнерскому разделу нет. Можно как-то продублировать или в другом месте посмотреть?

конфликс - док-т висит, потом выскакивает ошибка, см. , там описание. Почистить можно попробовать, но у нас док-т большой. Каждую неделю или каждый день чистить? кто скажет при каком объеме записей такая потеха начинается? Думаю надо в причине разобраться, а не устранять следствие

я думаю, Слава не обидится. в общем цитата: "эскалация на сервере 1С существует"

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

лог трассировки не сохранил, но там было событие ROLLBACK, но касалось оно отката начатой транзакции проведения, в общем я сделал вывод, что это сервер 1с посылает команду, а на СУБД все нормально

там в ресурсе действительно стоит Измерение, но как такое может, если регистраторы разные?

а итогов что, нету, что ли?

где одинаковые? в рабочей и в чистой копии? если так, то разные. Я же в копии вообще руками и склады и номенклатуру заново создавал

огромное спасибо за ссылку. Из нее думаю можно заявить, ЭСКАЛАЦИЯ МЕНЕДЖЕРОМ БЛОКИРОВОК СЕРВЕРА 1С в управляемом режиме СУЩЕСТВУЕТ. И хотя в основном речь идет о записи больших наборов записей, но и при наличии большого объема существующих записей (даже при записи небольшого набора) эскалация возможна.

итогов нету, это не накопления регистр, а сведений

, . Даже не знаю, что теперь делать. Руки опускаются. 1С как всегда посчитали, что сами лучше знают. В sql хоть существует команда, которая отключает эскалацию принудительно. А что с сервером 1с делать?

не хочется верить в , в ссылке фигурировала цифра 90 тыс. записей в регистре (при ней начинается эскалация). У нас такой объем за 4-5 дней набирается. Посмотрел УПП 1.3 один из последних релизов - там такой же механизм относительно Р.С. СписанныеТовары. Почему тогда это не поправили? Почему в конце проведения док-та не очищать движения по этому регистру, ведь записи в нем только при проведении нужны, в запросе партий?

Меня этот вопрос тоже интересует. По поводу того же регистра СписанныеТовары, который дико растёт. Скорее всего, эскалация это вынужденная мера, чтобы сократить структуры данных, обеспечивающие управляемые блокировки и хранящиеся в памяти процесса сервера. 90 тысяч это количество блокировок в одной транзакции. Этот РС нужен для проведения по партиям, которое выполняется регламентной процедурой по ночам, чтобы избежать блокировок на партиях в онлайне. Это долгий процесс, особенно, когда неразумные пользователи сбивают последовательность партионного учёта больше чем на год.

Потому что нужно отказываться от партионного учета и использовать РАУЗ. Так в 1С думают.

А сколько записей в документе на рабочей базе?

партионный учет и так вроде отключен (сейчас не могу посмотреть). СписанныеТовары вроде в любом случае двигаются.

в каждом док-те в базе записей не много - до 40 строк. В тестируемом мной примере вообще порядка 10 записей в наборе. Но в целом база больше 100 Гб. и в СписанныеТовары более 30 млн. записей

Так если партионного учета нет так отключи запись в РС. Он больше ни для чего не нужен. Это с точки зрения практики. Если хочется потратить время на теорию и изыскания то другой вопрос.

с точки зрения практики так можно. Хочется понять программистов 1С. В понедельник посмотрю еще посмотрю последнюю УПП 1.3 - всегда ли там СписанныеТовары пишутся или в зависимости от ведения партионного учета

У меня РАУЗ, а этот рс всё равно двигается

Найдите 10 причин по которой он нужен в таком случае )