|
Уменьшение конфликта блокировок при обмене РИБ | ☑ | ||
---|---|---|---|---|
0
Dwarrior
04.05.17
✎
10:27
|
Здравствуйте!
Есть база УТ 10.3, в ней создан новый план обмена, РИБ. База большая, 400Гб, по плану обмена выгружается довольно большой объем данных (реализация, контрагенты и пр.). Так вот, наблюдается "конфликт блокировки транзакций" при выгрузке файлов в дочерние базы (в базе в это время работают юзеры). Можно как-то минимизировать этот конфликт блокировок? Понимаю, что для целостности выгружаемых данных необходима блокировка изменений. Но все же, проблема есть. Есть несколько мыслей, не знаю, поможет ли: 1. Управляемые блокировки 2. План обмена сделать не РИБ/обмен по правилам обмена Подскажите, кто как боролся с этой проблемой? |
|||
1
Spieluhr
04.05.17
✎
10:30
|
1. Блокировки ставит платформа
2. Нет Не запускать обмен с почками одновременно. Сделать один сценарий, чтобы последовательно происходила загрузка/выгрузка по каждому узлу |
|||
2
Лефмихалыч
04.05.17
✎
10:36
|
смотря что именно блокируется
|
|||
3
mistеr
04.05.17
✎
10:50
|
(0) Выгружать чаще, меньше объем — меньше блокировок. Но не слишком часто. Найти золотую середину.
|
|||
4
Lama12
04.05.17
✎
11:09
|
(0) Есть у меня подозрение что подтверждение о приеме не приходят в базу из которой выгрузка идет.
|
|||
5
Dwarrior
04.05.17
✎
11:33
|
(4) Нет, с этим все нормально, после обмена размер выгружаемого файла уменьшается.
(2) Да похоже, что блокируется все - ничего ввести нельзя, только посмотреть (1) Обмены с узлами были разнесены по времени. Конфликт блокировок возникает при выгрузке файла в один узел, там данных много, файл выгружается 10 мин примерно. |
|||
6
бомболюк
04.05.17
✎
11:35
|
дл начала я бы профайлером нашел "узкое место", если таковое есть - таблица, на которой все толкаются. Если такая есть - надо оптимизировать операции с ней.
|
|||
7
mistеr
04.05.17
✎
11:42
|
(6) Это таблица изменений. Что тут можно оптимизировать?
|
|||
8
Dwarrior
04.05.17
✎
11:43
|
(6) Хотя бы в двух словах - как?:) Знаю о нем немного. Он покажет какие запросы выполняются и время выполнения запросов?
|
|||
9
Fragster
гуру
04.05.17
✎
11:44
|
в настройках поставить количество элементов в транзакции = 1
|
|||
10
Fragster
гуру
04.05.17
✎
11:44
|
потом (3)
|
|||
11
Fragster
гуру
04.05.17
✎
11:45
|
(7) есть тема сделать "виртуальные" узлы с round-robin регистрацией, при выгрузке - пихать все в один файл
|
|||
12
Fragster
гуру
04.05.17
✎
11:46
|
да и выгрузку можно также делать параллельной
|
|||
13
бомболюк
04.05.17
✎
11:49
|
в профайлере ставим 2 события: Lock(aquire) и Lock(cancel), потом фильтр на поле Duration >= 1. В выводимых полях надо ObjectId1, ObjectId2 обязательно, по ним потом таблицу вычислишь. Вывод результатов сделай в таблицу какую нить, потом анализируй суммарное значение Duration для каждого объекта, где максимум - там узкое место.
|
|||
14
Fragster
гуру
04.05.17
✎
11:53
|
(13) не проще через технологический журнал смотреть?
|
|||
15
бомболюк
04.05.17
✎
11:54
|
(14) ну кто к чему привык ;-)
|
|||
16
Cyberhawk
04.05.17
✎
11:57
|
(12) уже сделано в стороннем платном решении, а вариация на тему (11) - разбивать по виртуальным узлам в момент выгрузки (забора изменений с реального узла), а не регистрации
|
|||
17
Dwarrior
04.05.17
✎
11:58
|
(13) (14) спасибо, будем анализировать.
(9) это правда помогает? |
|||
18
pavig
04.05.17
✎
12:00
|
(9)
А это не на загрузку ставится? |
|||
19
mistеr
04.05.17
✎
12:05
|
(11) Интересно. Пробовал реализовать?
|
|||
20
Fragster
гуру
04.05.17
✎
12:09
|
(18) я не помню уже. но это первая настройка, которую надо сделать.
|
|||
21
Fragster
гуру
04.05.17
✎
12:10
|
(19) пробовал. когда затык именно в регистрации - помогает.
|
|||
22
Fragster
гуру
04.05.17
✎
12:10
|
да и в выгрузке тоже, немного.
|
|||
23
Fragster
гуру
04.05.17
✎
12:11
|
но это было давно (несколько лет назад)
|
|||
24
vi0
04.05.17
✎
13:01
|
(0) рассмотри то, что блокировку для РИба устанавливает метод ЗаписатьИзменения()
возможно, сделать полностью свой обмен, со своими выборками изменений, например запросом выгрузку изменений конфигурации тоже как-то изолировать но, полагаю, это трудоемкая задача |
|||
25
undertaker
04.05.17
✎
13:38
|
еще может помочь переход на регистрацию изменений по правилам регистрации объектов, если это сейчас не так сделано
|
|||
26
pavig
04.05.17
✎
13:53
|
(25) Каким образом это может помочь?
|
|||
27
vi0
04.05.17
✎
13:53
|
(26) поможет если изначально было сделано криво
|
|||
28
Spieluhr
04.05.17
✎
13:54
|
(5) по науке в ЦБ юзеры только на просмотр должны работать, тогда и проблем с блокировками не будет
|
|||
29
vi0
04.05.17
✎
14:02
|
+(28) да, кстати
что за реализации выгружаются в периферию? |
|||
30
pavig
04.05.17
✎
14:04
|
(27) Да каким образом помочь-то может? Там же только условия регистрации прописываются? Не?
|
|||
31
MaxS
04.05.17
✎
14:08
|
Давно делал так - выделял одну центральную базу только для обменов, пользователей там небыло. Центральный офис сидел рядом в РИБ.
|
|||
32
Dwarrior
04.05.17
✎
14:38
|
(31) А та дочерняя база РИБ (где сидит центральный офис), когда обменивалась с центральной, не ловила конфликт блокировок? Не вижу выигрыша: данное, забитое юзером, все равно надо выгружать, неважно дочерняя база у тебя или центральная.
Допустим, в моем примере вынесу обмен с дочерними узлами из центра в отдельную базу - так ведь данные в эту дочернюю все равно выгружать/загружать придется? (25) С регистрацией изменений считаю проблем нет - подписки на события, которые фильтруют ненужные для обмена данные. Т.е. в таблицах рег. изменений только реальные данные. |
|||
33
vi0
04.05.17
✎
15:19
|
(30) можно фильтрацию делать в момент выгрузки, тогда выгрузка будет проходить дольше, блокировки дольше
|
|||
34
Fragster
гуру
04.05.17
✎
15:20
|
(33) правильно делать и в момент регистрации и в момент выгрузки, потому что условия выгрузки могут поменяться
|
|||
35
vi0
04.05.17
✎
15:21
|
(34) не согласен - это уже пахнет копипастой
условия поменяются - перерегистрировать принудительно |
|||
36
Serg_1960
04.05.17
✎
15:25
|
(32) "Выделенный" (т.е. без пользователей) центральный узел(ЦУ) имеет смысл делать, когда у него много подчинённых узлов(ПУ). Если немного подумать, то станет понятно почему: в то время, когда ПУ однократно обменивается только с ЦУ, ЦУ приходится многократно обмениваться с каждым ПУ по очереди. Разумеется это касается топологии РИБ типа "звезда".
PS: не знаю используют ли сейчас такие термины, как "активная звезда"(когда в центре сервер) и "пассивная звезда"(когда в центре концентратор). |
|||
37
pavig
04.05.17
✎
15:28
|
(33) ну так бы сразу и написал - фильтрацию перенести на момент регистрации, а не на момент выгрузки
|
|||
38
pavig
04.05.17
✎
15:29
|
(35) Я думаю что логика принимается в зависимости от обстоятельств
|
|||
39
Serg_1960
04.05.17
✎
15:32
|
Кстати: самый полезный совет из всего сказано - это (9).
Но есть один нюанс в базах с планом обмена "РИБ": если сеанс обмена завершится ошибкой, то в можно получить ситуации, когда проведённый документ будет без движений (с неполным "комплектом" движений) или когда движения окажутся без регистратора в базе. |
|||
40
vi0
04.05.17
✎
15:38
|
(38) так можно сказать про любую задачу
|
|||
41
vi0
04.05.17
✎
15:40
|
(37) не я писал про это
|
|||
42
Serg_1960
04.05.17
✎
15:41
|
PS: Я бы осторожно порекомендовал бы первоначально уменьшить время между сеансами обмена.
|
|||
43
vi0
04.05.17
✎
15:41
|
(39) почему самый полезный?
|
|||
44
pavig
04.05.17
✎
15:44
|
(43) +1
|
|||
45
Вафель
04.05.17
✎
15:47
|
Буферный узел самый лучший вариант пока
|
|||
46
MaxS
04.05.17
✎
15:48
|
(32) Как уже сказали имеет смысл если много периферийных баз. Каждый обмен блокирует какую-нибудь таблицу. А для ЦБ-ЦБ блокировка будет один раз. Оптом должно быть быстрее.
Минусы правда - лишняя база, ещё один обмен, кто-то должен следить за этим. |
|||
47
Dwarrior
04.05.17
✎
15:55
|
В-общем, ситуация понятна. Принципиально ничего сделать нельзя. Из вторичных мер:
1. Буферный узел обмена 2. Выгрузка порциями(Колво элементов в транзакции) 3. Поиск профайлером возможных "узких" мест в операции выгрузки данных, которые, может быть, удастся оптимизировать. Всем большое спасибо! |
|||
48
Dwarrior
04.05.17
✎
15:55
|
Приятно было поговорить с умными людьми:)
|
|||
49
vi0
04.05.17
✎
16:04
|
(47) узкие места давно известны и описаны, в том числе в документации
искать не нужно |
|||
50
Dwarrior
04.05.17
✎
16:39
|
(49) Подскажите пожалуйста, в какой документации? И какие например места?
|
|||
51
Serg_1960
04.05.17
✎
17:39
|
(43) "почему самый полезный" - потому, что самый простой и оперативный в реализации на конкретном узле. Без лишних телодвижений.
|
|||
52
MaxS
04.05.17
✎
17:53
|
Как вариант - отказаться от обменов и всем переехать в облако.
|
|||
53
youalex
04.05.17
✎
17:58
|
теоретически, можно рабочую базу реплицировать средствами скуля, и обмены с реплики отправлять. Отчеты, кстати, тоже, можно за данными туда отправлять.
|
|||
54
vi0
04.05.17
✎
18:21
|
(51) это не самый полезный, а самый простой и оперативный) и то не факт)
|
|||
55
vi0
04.05.17
✎
18:23
|
(50) см поиск на its.1c.ru все что касается блокировок и планов обмена
|
|||
56
Serg_1960
05.05.17
✎
09:57
|
(54) Расставлю точки над "и": совет - полезный, а метод - самый простой и оперативный. Хех... о чём мы спорим? (риторический вопрос)
|
|||
57
Fragster
гуру
05.05.17
✎
11:18
|
(39) со следующим пакетом движения долетят
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |