Управляемые блокировки на оборотный регистр #808930

Коллеги, добрый день! Есть не типовой оборотный регистр в УПП. У УПП режим блокировок управляемый. У регистра автоматический. Поможет ли перевод оборотного регистра в управляемый режим блокировок? Надо ли устаннавливать управляемую блокировки для увеличения параллельности? Контроля остатков по этому регистру нет(и быть не может, так как он не остаточный)

Прочитай мануалы про сочетание режимов блокировок конфигурации и объектов, и вопрос отпадет.

Поможет ли перевод оборотного регистра в управляемый режим блокировок? Имел ввиду что система безбожно тормозит, гов-ода нет(есть, но мало). Грешу на блокировки автоматические

Нет. Если не понял первопричину тормозов. Замеры производительности делал?

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

Делал, там везде значения меньше процента в обработке проведения, хз, что делать... Загрузка документов идет с интернета, документы загружаются и проводятся секунд за 8, что очень долго. Погуглил, решил включить режим "Read committed snapshot" на скуле, подумал, что проблема где-то в блокировках может быть

Может есть идеи у кого, как поправить ситуацию? Нашел обработку, которая смотррит блокировка, он она на УФ(можно переделать, но я не уверен что это оправдано, так как не выявил проблему)

Разделение итогов включено? (в конфигураторе и предприятии)

У регистра не включено, в предприятии тоже включается?

Включи, и там, и там.

В предприятии было включено, в конфигураторе нет - жесть какая-то

Может у тебя загрузка из интернета долго идет. Попробуй записывать без проведения и сравни время. Если все же запись или проведение, то найди тормозящий запрос и профилируй его в скуле.

У меня без проведения не выйдет, там все завязано, был еще вариант отдельно грузить проводки, но тогда по времени тоже самое должно выйти. А тормозящих запросов нет, были, но они переписаны, если я буду оптимизировать строчки кода по 0,5% я эти 0,5% и выиграю, прям безысходность(

Подскажите, в УПП же управляемые блокировки? не будет граязного чтения если включу режим Read commited snapshot на скуле?

проверь еще в замере производительности время выполнения в целом по функциям - скорее всего в какой-то из них алгоритм в целом неэффективно написан, 100 строк по 0,5% - уже 50%. Read commited snapshot включать можно, это платформа вообще должна сама делать начиная с 8.3 ЕМНИП. Но ты вообще не совсем правильно идешь. С чего ты взял, что у тебя тормозят именно блокировки? В монопольном режиме быстро проводится? Если в монопольном режиме тоже тормозит, то это сто процентов НЕ блокировки.

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

Позовите специалиста.

Хочу получить свой опыт, на фиксе не так много развлечений)

Значит в коде не "все ок". Если код не очень большой, можешь сюда его выложить, желательно вместе с замером.

"В монопольном тоже медленно" // Как проверял? Конкретнее как ты делал монопольным режим?

Но 8 секунд откуда-то берутся. В замере ты их видишь или нет?

А УПП полностью типовая?

Начните с понимания того как считает время Замер производительности. Что в нем учитывается, а что нет. С блокировками проблем у вас точно нет

+ Например длительность выполнения запроса при открытии ДС (дин. списка) замер не учитывает: форма может открываться 5 секунд, а по замеру 0.5 секунд :)

Нет, сильно переписанная Клиентские и серверные вызовы С формой не работаю, загрузка без форм

Обрати внимание на первое слово

Подскажите, плз. Есть сейчас не типовой регистр остатков. Если я включу на sql read commited snapshot isolation - при контроле остатков у этого регистра без наложения управляемых блокировок могут считаться не правльные данные? Режим управления блокировк у конфы сейчас управляемый

>В обычном режиме MS SQL Server каждый делает попытку наложить блокировку на строку с нужной записью остатков. Когда вы включите версионирование, то каждый пользователь прочитает ВЕРСИЮ, которая предварительно будет помещена из основной базы в tempdb. Затем сделает транзакцию и удалит версию. (текст с сайта Гилева) Я правильно понимаю, что все прочитают одни и те же остатки, допустим остаток 50, у 10 пользователей нужно добавить расход по 50, в итоге у нас полчится остаток -450?

Вопрос закрыт, нашел статью на ИС, которая отвечает что без управляемых блокировок ничерта не отработает. Однако, из справки в ИТС делаю вывод, что даже если мы не наложим блокировку через "Новый блокировка данных" все отработает корректно. "Если же установлен режим Управляемый, то, независимо от того, какие режимы управления блокировками установлены для конкретных объектов конфигурации (об этом смотри далее), при записи, скажем, документа система всегда будет самостоятельно устанавливать необходимые управляемые блокировки, которые будут обрабатываться собственным менеджером транзакционных блокировок. Этот режим предназначен для работы всей конфигурации только с управляемыми блокировками в транзакции." Я так понял, блокировки могут быть избыточными, ну и хрен с ним, они будут и их прописывать в ручную не нужно. Завтра ставлю режим в скл)

read commited snapshot isolation дает эффект за счет того, что запрос чтения остатков внутри транзакции не блокирует таблицу остатков до конца этой транзакции

Забей. Никакого выхлопа от твоих телодвижений не будет.

Но управляемые блокировки будут наложены в любом случае на уровне 1С, значит и в СУБД будут

А что порекомендуете?

Ничего. Проблема не в блокировках. Что в автоматических, что в управляемых - если ты не контролируешь остатки в регистре, а, конкретнее, если ты не читаешь регистр в транзакции проведения - то никакого смысла заморачиваться с блокировками нет. Единственное, для остаточных регистров следует отключить разделение итогов.

При проведении документа много где идет чтение регистра. Почему отключчить? Может, наоборот - включить? Чтобы данные туда быстрее писались

Вы же сами написали в , что чтения - нет

Блин, а в чем проблема? И сервер настроили по инструкции с ИТС, а он работает не на полную мощность, проц процентах на 40 крутится постоянно, память тоже не вся отожрана. Код не очень плохой, а ведь проводится медленно Извините, спрашивал для одного не типового регистра, всего разных не типовых регистров в базе штук 20

Регистров накопления*

"проц процентах на 40 крутится постоянно" Прекрасный показатель утилизации.

"Код не очень плохой, а ведь проводится медленно " - вот и надо искать причину, а не бросаться делать "что-нибудь".

Вот, можно почитать

загрузку делаете надеюсь не через COM?

наборзаписей.Прочитать ведь не используете?

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

Не смотрел, вроде, не через ком А это критично? Дак собирал, все на проведение уходит