Уменьшение конфликта блокировок при обмене РИБ #796757

Здравствуйте! Есть база УТ 10.3, в ней создан новый план обмена, РИБ. База большая, 400Гб, по плану обмена выгружается довольно большой объем данных (реализация, контрагенты и пр.). Так вот, наблюдается "конфликт блокировки транзакций" при выгрузке файлов в дочерние базы (в базе в это время работают юзеры). Можно как-то минимизировать этот конфликт блокировок? Понимаю, что для целостности выгружаемых данных необходима блокировка изменений. Но все же, проблема есть. Есть несколько мыслей, не знаю, поможет ли: 1. Управляемые блокировки 2. План обмена сделать не РИБ/обмен по правилам обмена Подскажите, кто как боролся с этой проблемой?

1. Блокировки ставит платформа 2. Нет Не запускать обмен с почками одновременно. Сделать один сценарий, чтобы последовательно происходила загрузка/выгрузка по каждому узлу

смотря что именно блокируется

Выгружать чаще, меньше объем — меньше блокировок. Но не слишком часто. Найти золотую середину.

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

Нет, с этим все нормально, после обмена размер выгружаемого файла уменьшается. Да похоже, что блокируется все - ничего ввести нельзя, только посмотреть Обмены с узлами были разнесены по времени. Конфликт блокировок возникает при выгрузке файла в один узел, там данных много, файл выгружается 10 мин примерно.

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

Это таблица изменений. Что тут можно оптимизировать?

Хотя бы в двух словах - как?:) Знаю о нем немного. Он покажет какие запросы выполняются и время выполнения запросов?

в настройках поставить количество элементов в транзакции = 1

потом

есть тема сделать "виртуальные" узлы с round-robin регистрацией, при выгрузке - пихать все в один файл

да и выгрузку можно также делать параллельной

в профайлере ставим 2 события: Lock(aquire) и Lock(cancel), потом фильтр на поле Duration >= 1. В выводимых полях надо ObjectId1, ObjectId2 обязательно, по ним потом таблицу вычислишь. Вывод результатов сделай в таблицу какую нить, потом анализируй суммарное значение Duration для каждого объекта, где максимум - там узкое место.

не проще через технологический журнал смотреть?

ну кто к чему привык ;-)

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

спасибо, будем анализировать. это правда помогает?

А это не на загрузку ставится?

Интересно. Пробовал реализовать?

я не помню уже. но это первая настройка, которую надо сделать.

пробовал. когда затык именно в регистрации - помогает.

да и в выгрузке тоже, немного.

но это было давно (несколько лет назад)

рассмотри то, что блокировку для РИба устанавливает метод ЗаписатьИзменения возможно, сделать полностью свой обмен, со своими выборками изменений, например запросом выгрузку изменений конфигурации тоже как-то изолировать но, полагаю, это трудоемкая задача

еще может помочь переход на регистрацию изменений по правилам регистрации объектов, если это сейчас не так сделано

Каким образом это может помочь?

поможет если изначально было сделано криво

по науке в ЦБ юзеры только на просмотр должны работать, тогда и проблем с блокировками не будет

+ да, кстати что за реализации выгружаются в периферию?

Да каким образом помочь-то может? Там же только условия регистрации прописываются? Не?

Давно делал так - выделял одну центральную базу только для обменов, пользователей там небыло. Центральный офис сидел рядом в РИБ.

А та дочерняя база РИБ (где сидит центральный офис), когда обменивалась с центральной, не ловила конфликт блокировок? Не вижу выигрыша: данное, забитое юзером, все равно надо выгружать, неважно дочерняя база у тебя или центральная. Допустим, в моем примере вынесу обмен с дочерними узлами из центра в отдельную базу - так ведь данные в эту дочернюю все равно выгружать/загружать придется? С регистрацией изменений считаю проблем нет - подписки на события, которые фильтруют ненужные для обмена данные. Т.е. в таблицах рег. изменений только реальные данные.

можно фильтрацию делать в момент выгрузки, тогда выгрузка будет проходить дольше, блокировки дольше

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

не согласен - это уже пахнет копипастой условия поменяются - перерегистрировать принудительно

"Выделенный" (т.е. без пользователей) центральный узел(ЦУ) имеет смысл делать, когда у него много подчинённых узлов(ПУ). Если немного подумать, то станет понятно почему: в то время, когда ПУ однократно обменивается только с ЦУ, ЦУ приходится многократно обмениваться с каждым ПУ по очереди. Разумеется это касается топологии РИБ типа "звезда". PS: не знаю используют ли сейчас такие термины, как "активная звезда"(когда в центре сервер) и "пассивная звезда"(когда в центре концентратор).

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

Я думаю что логика принимается в зависимости от обстоятельств

Кстати: самый полезный совет из всего сказано - это . Но есть один нюанс в базах с планом обмена "РИБ": если сеанс обмена завершится ошибкой, то в можно получить ситуации, когда проведённый документ будет без движений (с неполным "комплектом" движений) или когда движения окажутся без регистратора в базе.

так можно сказать про любую задачу

не я писал про это

PS: Я бы осторожно порекомендовал бы первоначально уменьшить время между сеансами обмена.

почему самый полезный?

+1

Буферный узел самый лучший вариант пока

Как уже сказали имеет смысл если много периферийных баз. Каждый обмен блокирует какую-нибудь таблицу. А для ЦБ-ЦБ блокировка будет один раз. Оптом должно быть быстрее. Минусы правда - лишняя база, ещё один обмен, кто-то должен следить за этим.

В-общем, ситуация понятна. Принципиально ничего сделать нельзя. Из вторичных мер: 1. Буферный узел обмена 2. Выгрузка порциями(Колво элементов в транзакции) 3. Поиск профайлером возможных "узких" мест в операции выгрузки данных, которые, может быть, удастся оптимизировать. Всем большое спасибо!

Приятно было поговорить с умными людьми:)

узкие места давно известны и описаны, в том числе в документации искать не нужно

Подскажите пожалуйста, в какой документации? И какие например места?

"почему самый полезный" - потому, что самый простой и оперативный в реализации на конкретном узле. Без лишних телодвижений.

Как вариант - отказаться от обменов и всем переехать в облако.

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

это не самый полезный, а самый простой и оперативный) и то не факт)

см поиск на its.1c.ru все что касается блокировок и планов обмена

Расставлю точки над "и": совет - полезный, а метод - самый простой и оперативный. Хех... о чём мы спорим? (риторический вопрос)

со следующим пакетом движения долетят