Вход | Регистрация
    1  2   

Эскалация блокировок

Эскалация блокировок
Я
   Franchiser
 
06.05.19 - 18:51
В двух сеансах выполняется удаление операций: отдельно чистятся регистры с отбором по регистратору, отдельно проставляется пометка на удаление и выполняется импорт.
Операции грузятся в 2х сессиях за разный период.
В операциях может быть больше 1000 строк. При этом возникают блокировки. Как устранить проблему с блокировками.
 
 
   palsergeich
 
1 - 06.05.19 - 19:45
Какие блокировки идут на эскалацию?
Управляемые или sql?
Если sql гугли флаг 1211 и 1214
   palsergeich
 
2 - 06.05.19 - 19:46
(1) ой 1211 и 1224
   Franchiser
 
3 - 06.05.19 - 20:03
Да, дошел до этого, админ говорит что достаточно 1211
   vde69
 
4 - 06.05.19 - 20:21
для начало хотелось-бы узнать название и версию субд, все-же есть разница между ораклом и файловой :)
   Маша с уралмаша
 
5 - 06.05.19 - 22:08
(4) а тебе какая разница, ты все равно не сможешь
   palsergeich
 
6 - 06.05.19 - 22:09
(4) 1211 и 1224 это флаги mssql, согласие автора выдало субд
   Маша с уралмаша
 
7 - 06.05.19 - 22:11
(0) а что ты хотел сказать говоря что может быть больше 1000 строк?
   palsergeich
 
8 - 06.05.19 - 22:12
(7) Ну 5000 - это эскалация SQL/
   palsergeich
 
9 - 06.05.19 - 22:13
Уточню - это лядский зашитая судя по всему хардкодом триггер эскалации на таблицу
   Маша с уралмаша
 
10 - 06.05.19 - 22:15
(8) ну да, больше тыщи это больше 5 тыщ по правилам арифметика автоматически, я и забыл
   Маша с уралмаша
 
11 - 06.05.19 - 22:16
(9) что ты несёшь?
   palsergeich
 
12 - 06.05.19 - 22:16
(10) Больше тысячи - значит и больше 5ти возможно
   Маша с уралмаша
 
13 - 06.05.19 - 22:18
(12) больше одной записи значит и больше 5  тыщ возможно да? Рукалицо
   palsergeich
 
14 - 06.05.19 - 22:21
(11) когда запрос пытается применить к одному объекту (к таблице или индексу) более 5000 блокировок на уровне записи или страницы. Значение 5000 блокировок взято из документации, но на практике SQL Server иногда продолжает использовать блокировки уровня записи или страниц и при количестве в сотни тысяч таких блокировок. При этом SQL Server никогда не производит эскалацию с уровня записи до уровня страницы, а сразу пытается наложить блокировку на таблицу;

https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms184286(v=sql.105)

(13) А что нет?
   vde69
 
15 - 06.05.19 - 22:21
(0) ну как-бы при удалении (пометке) штатными средствами помимо объекта и его ТЧ еще есть планы обмена, последовательности, журналы, критерии поиска.... обычно сабж возникает не из-за эсколации а из-за дедлоков на общих таблицах (обычно это последовательности)

с чего Вы решили, что у Вас блокировки именно из-за эскалации блокировок? для начала посмотрите статистику ожидания блокировок.....
   palsergeich
 
16 - 06.05.19 - 22:22
(14) ссылка криво вставилась движком форума. Закрывающую скобку тоже надо в адресной строке поставить
   palsergeich
 
17 - 06.05.19 - 22:22
(13) ТТы злой такой? У тебя проблемы в жизни?
   vde69
 
18 - 06.05.19 - 22:23
   palsergeich
 
19 - 06.05.19 - 22:26
(15) Я буквально 2 недели назад столкнулся с похожей проблемой:
Много доков с ТЧ около 1000 записей.
И зараза постоянные эскалации на РБ Хозрасчетный. Именно эскалации. Не планы обмена, не последовательности, не ожидания.
   vde69
 
20 - 06.05.19 - 22:28
(19) ну хозрасчетный то-же слабое место из-за второй таблицы с субконто, но автор написал, что движения он чистит отдельно по регистратору...
   palsergeich
 
21 - 06.05.19 - 22:29
(18) Просто параллельно проводишь в 3 потока приходные накладные, и пошла красота.
С расходными такой беды нет.
   palsergeich
 
22 - 06.05.19 - 22:33
(20) Эскалация на основной таблице, не на с субконто.
   Маша с уралмаша
 
23 - 06.05.19 - 22:33
(21) просто приход надо тоже расходными делать, вид операции приход добавить, и проблем не будет
   Franchiser
 
24 - 07.05.19 - 01:02
Записей в операциях может быть у меня и 1000, и 5000, максимум 500000.
Уровень изоляции на продуктивном сервере read comitted, на тестовом snapshot read comitted.Ошибка наблюдается на обоих.
   Franchiser
 
25 - 07.05.19 - 01:27
(20) в одной сессии может записываться операция на 100000 и больше, в другой сессии чистится движения операции и возникает ошибка таймаута.
   Franchiser
 
26 - 07.05.19 - 09:46
При выполнении удаления движений по регистратору ставятся какие либо блокировки? И чему равно количество блокировок, количеству удаляемых строк?
   Cyberhawk
 
27 - 07.05.19 - 09:56
Может ты еще читаешь набор записей перед тем, как удалять?
   Franchiser
 
28 - 07.05.19 - 10:57
нет, не читаю: в одной сессии создаю набор записей по регистратору и записываю, в другой записываю пустые наборы по другим регистраторам
   Cyberhawk
 
29 - 07.05.19 - 11:28
Отключить итоги у регистра может помочь
   H A D G E H O G s
 
30 - 07.05.19 - 11:54
Текст ошибки то какой?
 
 
   Cyberhawk
 
31 - 07.05.19 - 11:59
(30) Судя по (25) таймаут на упр.
   Glup0sti
 
32 - 07.05.19 - 13:36
(0) 2 подхода:
либо ты делишь документы так, чтобы в двух сессиях не пересекались измерения (для РБ + счет) в удаляемых движениях
либо (27) или его другой вариант отключение текущих итогов, период рассчитанных итогов меньше на месяц, чем периоды изменяемых движений (Смотря на какой таблице была эскалация может и не помочь, но откуда ты взял что у тебя эскалация? доказательства, что она происходит есть?)
   Franchiser
 
33 - 07.05.19 - 14:18
(30) Конфликт блокировок при выполнении транзакции: превышено максимальное время ожидания предоставления блокировки
   Franchiser
 
34 - 07.05.19 - 14:19
(32) у меня движения по регистру накопления
   Franchiser
 
35 - 07.05.19 - 14:21
(32) пока нет.
Не получается настроить ТЖ. Не работает фильтрация на базу и каталоги создаются с непонятными числами: не соответсьвуют ни pid процессов , ни номерам соединений
   Franchiser
 
36 - 07.05.19 - 14:54
При включении ТЖ получаются такие каталоги:
1cv8c_5900
1cv8c_11796
1cv8s_18316
mmc_3308
1cv8s_13096
1cv8_17588
и т.д.
Что означают числа?
   Franchiser
 
37 - 07.05.19 - 14:58
Везде пишут что должны быть такие катлоги:
ragent_###, rmngr_####, rphost_###
   Маша с уралмаша
 
38 - 07.05.19 - 14:59
М-да..
   Cyberhawk
 
39 - 07.05.19 - 15:21
Так ты на клиенте включит ТЖ
   Cyberhawk
 
40 - 07.05.19 - 15:21
*включил
   Cyberhawk
 
41 - 07.05.19 - 15:21
А ты там кем?
   rphosts
 
42 - 07.05.19 - 15:24
(5) не хами!
   rphosts
 
43 - 07.05.19 - 15:25
(36) рп?
   Franchiser
 
44 - 07.05.19 - 16:44
(39) при некоторых настройках события пишутся, но не TLOCK
   Franchiser
 
45 - 07.05.19 - 16:44
(43) что рп?
   Franchiser
 
46 - 07.05.19 - 16:50
(40) если три кластера серверов то с кем будет работать?
   Cyberhawk
 
47 - 07.05.19 - 19:22
Сколько кластеров не имеет значения, ведь инфобаза всегда зарегистрирована должна быть только в одном кластере. А если у тебя это не так, то ты ССЗБ. А если ты кластерами называешь рабочие серверы кластера, то вдвойне :)
   vde69
 
48 - 07.05.19 - 22:04
(46) кластер 1с ВСЕГДА имеет ОДИН мастер сервер, именно он разруливает 1с-шные блокировки на весь кластер (на все сервера кластера и все процессы их),

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

(25) 100000 записей в ОДНОЙ транзакции? учти, что эта транзакция идет совсем не быстро (26) при записи пустого набора в регистр ставится блокировка по отбору, то есть если для регистров с регистратором получить лишнюю блокировку тяжело, там отбор только по регистратору, а вот с независимыми регистрами вполне реально получить блокировку на весь регистр целиком.
В дополнение тут уже говорили про пересчет итогов, при больших транзакциях однозначно итоги нужно отключать и потом их пересчитывать отдельно
   Franchiser
 
49 - 07.05.19 - 22:17
(47) настроил на сервере под пользователем 1С. Теперь пишет в ТЖ.
   Franchiser
 
50 - 07.05.19 - 22:18
События tlock нет в журнале
   Franchiser
 
51 - 07.05.19 - 22:20
В ТЖ попадаются такие строки:
38:06.577005-161148005,CONN,1,process=rphost,p:processName=bd,OSThread=2412,ClientID=293,Txt=Outgoing connection closed
   Franchiser
 
52 - 07.05.19 - 22:22
Содержание файл настройки:
<?xml version="1.0" encoding="UTF-8"?>

<config xmlns="http://v8.1c.ru/v8/tech-log">;
    <log location="C:\Users\USR1CV8\AppData\Local\Temp\log_tj_823aefe5-8375-4dfa-ad58-7542f1189c7c" history="1">
        <event>
            <ne property="name" value=""/>
            <eq property="p:processName" value="bd"/>
        </event>
        <property name="all"/>
    </log>
</config>
   Franchiser
 
53 - 07.05.19 - 22:26
(48) запрос в (18) что должно вернуть, какую то таблицу?
   vde69
 
54 - 07.05.19 - 22:29
(53) коды причин ожидания блокировок, 

там сразу будет видно это дедлок или что-то еще
   Franchiser
 
55 - 07.05.19 - 22:33
(54) я моделирую ситуацию на тестовой базе: запускаю в 2х сессиях обработку. В какой момент нужно выполнять этот запрос? я не знаю когда возникнут блокировки.
   vde69
 
56 - 07.05.19 - 22:39
(55) когда запускаешь, только в твоем случае параметры подкрути, а то 300 минут это для тебя долго...

поставь минут 20, например так

EXEC track_waitstats 20, 1

и сразу после запуска запускай свои обработки на нескольких сеасах
   Franchiser
 
57 - 07.05.19 - 22:41
(56) Завтра попробую, спасибо
   Franchiser
 
58 - 07.05.19 - 22:44
(56) в этом скрипте нельзя поставить фильтр на базу?
   vde69
 
59 - 07.05.19 - 22:46
(58) я не знаю, скрипт использует штатный сбор статистики а есть-ли там возможность фильтрануть по базе - читать надо, я никогда не заморачивался
   Feanor
 
60 - 07.05.19 - 23:12
Занятно, у ТС конфликт на управляемых блокировках, но ему упорно продают идею анализировать ожидания на СУБД, а также то, что это может быть дэдлок на СУБД :)
   Franchiser
 
61 - 07.05.19 - 23:24
(60) что вы предлагаете анализировать?
   vde69
 
62 - 07.05.19 - 23:26
(60) получить конфликт на управляемых блокировках в автоматическом режиме может быть 2х типов

1. ожидание освобождения при очень длительной транзакции (напоминаем типовой таймаут 10 минут), на объемах автора транзакции должна быть 1..2 минуты.
2. дедлок, да на управляемых его получить очень сложно, но учитывая все-же довольно длительную транзакцию 1...2 мин, я предполагаю, что блокировка возникает в авто режиме на небольшое время с момента записи и до фиксации транзакции, то есть это наверно секунд 15 при фиксированым порядком таблиц для блокировки, но вот если в авто режим мы влезаем грязными ручками и явным образом меняем порядок блокировки таблиц для разных типов документов - то тут и будет дедлок...
   Feanor
 
63 - 07.05.19 - 23:40
(61) события TLOCK и TTIMEOUT в технологическом журнале
   Feanor
 
64 - 07.05.19 - 23:44
(62) откуда инфа, что у автора автоматический режим управления блокировками?

в автоматическом режиме конфликта на управляемых блокировках не может быть

Если случился конфликт на управляемых блокировках, то до блокировок на уровне СУБД дело не дошло, их не нужно анализировать от слова "совсем"
   Feanor
 
65 - 07.05.19 - 23:45
+(64) и еще момент, дэдлок или нет - понятно по тексту ошибки, у автора явный конфликт блокировок (не дэдлок)
   Franchiser
 
66 - 08.05.19 - 00:22
у меня моделируется ситуация следующая:
1. Записывается операция по оборотному регистру накопления объемом примерно 500000 строк в одной сессии
2. В другой сессии улаляются движения и формируются операции примерно по 10-20 тыс строк в опер.
Т.к. регистр накопления оборотный то отключать итоги не имеет смысла.
Пока не рассматриваем вариант уменьшение строк в операциях.
Может быть конечно я неправильно записываю операции: 1. Записваю доеумент 2. Создаю набор 3. Ставлю отбор на регистратор 4. Заполняю 5. Записываю. Возможно при создании набора нужно ставить управляемую блокировку в транзакции на организацию и период?
 
 Рекламное место пустует
   Franchiser
 
67 - 08.05.19 - 00:27
(63) нет этих событий в ТЖ
   rphosts
 
68 - 08.05.19 - 02:50
(48)в кластере 8.3 может быть более 1 центрального сервера.
   rphosts
 
69 - 08.05.19 - 03:06
(66) операция №1 у вас выполняет установку блокировки на 500000 строк таблицы оборотного РН и по столько-же строк на каждый из регистров и на всякие доп. таблицы (итоги оборотов за каждый месяц и т.п.). Вполне резонно что на большом наборе записей сервер СУБД решает что экономичнее и быстрее повысить гранулярность блокировки до таблицы.
Как писали флаг 1224 отключит эскалацию по числу записей, а 1211 по числу записей+памяти, но 1211 может криво отрабатывать.

>Возможно при создании набора нужно ставить управляемую блокировку в транзакции на организацию и период?
управляемые блокировки ставить нужно!!! примеры: http://catalog.mista.ru/public/144750/

>Пока не рассматриваем вариант уменьшение строк в операциях.
не зная все подробности нельзя точно сказать правильно ли вы делаете. Как вариант делать допроведение документов ночью. Не подходит?
   Маша с уралмаша
 
70 - 08.05.19 - 06:53
(62) ну и бред
   Feanor
 
71 - 08.05.19 - 08:24
(67) есть, просто у тебя криво ТЖ настроен
   Feanor
 
72 - 08.05.19 - 08:30
(69) да нет там блокировок на СУБД, см (33)
   Franchiser
 
73 - 08.05.19 - 09:41
(69) не нашел по ссылке способа как поставить блокировку на Период (месяц) это вообще возможно?
   Franchiser
 
74 - 08.05.19 - 09:42
(71) как настроить: не ставить фильтр на базу?
   Feanor
 
75 - 08.05.19 - 09:43
(73) для чего тебе блокировка? Ты читаешь остатки перед формированием движений и контролируешь их?
   Franchiser
 
76 - 08.05.19 - 09:44
"делать допроведение документов ночью"
сложилас ситуация , что обработку впервые запусттли в 2 сессии, вообще всегда в одну сессию грузили. Поэтому такого больше не будет.
   Feanor
 
77 - 08.05.19 - 09:45
(74) да, попробуй не ставить фильтр на базу

вот кусок рабочих настроек для разбора проблем с упр. блокировками:
<log location="E:\LOGS\TLOCK" history="8">
               <event>
                               <eq property="Name" value="TLOCK"/>
               </event>
               <event>
                               <eq property="Name" value="TTIMEOUT"/>
               </event>
               <event>
                               <eq property="Name" value="TDEADLOCK"/>
               </event>
           <property name="all"/>
</log>
   Franchiser
 
78 - 08.05.19 - 09:47
(75) нет не читаю. Блокировка для того чтобы гранулярность была меньше чем сейчас, чтобы 1я сессия могла создать движения в оборотном регистре по своей оргагизации +периоду, а во второй сессии по своей паре и они не мешали друг другу.
   Feanor
 
79 - 08.05.19 - 09:47
+(75) вдумайся немного, у тебя конфликт блокировок и решать эту проблему ты пытаешься с помощью наложения дополнительных блокировок. Кажется это немного бессмысленно :)
   Franchiser
 
80 - 08.05.19 - 09:50
ну так из за чего конфликт, у меня пишутся разные наборы по разным организациям, значит программа сама неоптимально ставит блокировки
   Franchiser
 
81 - 08.05.19 - 09:51
если я явно не указываю упр. блокировки, значит блокировки наложит какие то другие субд и 1с?
   Feanor
 
82 - 08.05.19 - 09:56
(78) тебе это ничем не поможет.

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

Поэтому выход для тебя - разделить запись в регистр на порции, не превышающие 100к (если у тебя 8.3, для 8.2 и того меньше) записей для того, чтобы не возникала эскалация.

При этом нужно будет как-то контролировать целостность записи всего огромного набора записей, но это кажется решаемо
   Feanor
 
83 - 08.05.19 - 09:58
(81) ты запор пытаешься лечить закрепляющими средствами, а это плохой путь :)

если ты явно не накладываешь блокировки, то СУБД и платформа сами наложат необходимые им блокировки (независимо от тебя, как бы ты ни старался)
   Franchiser
 
84 - 08.05.19 - 10:00
Ну уровне субд я уже отключил эскалацию ылагами трассировки. Кроме этого уровень изоляции snaoshot вообще вряд ли приводит к блокировкам в субд. По крайней мере обработка по просмотру блокировок в sql на этой базе их вообще не покаЗывает.
Осталось увидеть блокировки 1с в ТЖ.
   Franchiser
 
85 - 08.05.19 - 10:03
(83) я не собираюсь ничего лечить, просто хочу видеть блокировки в ТЖ как подтверждение того что это из-за записи большого количества строк в регистр накопления по регистратору
   Franchiser
 
86 - 08.05.19 - 10:07
Интересно, будет ли разница если записывать операции по-другому минуя набор записей:
1. Получать объект
2. Записывать движения
3. записывать объект
   Cyberhawk
 
87 - 08.05.19 - 11:00
Давно бы запустил хотя бы обработку Бурмистрова по отображению блокировок, либо через какие-нибудь ИР настроил и собрал ТЖ.
А этот ручной онанизм с настройкой ТЖ и разглядыванием текстовых файликов в каталогах разве что на экзамене у Морозова пригодится )
   ptiz
 
88 - 08.05.19 - 11:07
(79) " решать эту проблему ты пытаешься с помощью наложения дополнительных блокировок" - это имеет смысл при борьбе с дедлоками. Тогда разные транзакции культурно будут ждать друг друга в очереди.
   ptiz
 
89 - 08.05.19 - 11:08
(86) Покажи какие именно упр.блокировки накладываешь и перечисли отдельно все измерения регистров, которые записываешь.
   Franchiser
 
90 - 08.05.19 - 11:16
(87) именно ее и запускал, в тестовой базе вообще ничего не показывает
   Franchiser
 
91 - 08.05.19 - 11:17
(89) сейчас никакие упр. блокировки не накладываю
   palsergeich
 
92 - 08.05.19 - 11:18
(91) это ты так думаешь.
Это за тебя щедро платформа делает.
Смотри пространства имен события Tlock
   Franchiser
 
93 - 08.05.19 - 11:20
(92) посмотрю когда получу tlock  в тж
   Cyberhawk
 
94 - 08.05.19 - 11:25
(90) "в тестовой базе вообще ничего не показывает" // Не настроил значит как надо, не читал требований
   Franchiser
 
95 - 08.05.19 - 11:27
в рабочей показывает в тестлвлй нет: не считая списка пользователей.
Уровни изоляций в базах разные
   Feanor
 
96 - 08.05.19 - 11:28
(90) очевидно же, что она показывает блокировки на СУБД, а у тебя таймаут на управляемых :)
   Franchiser
 
97 - 08.05.19 - 11:29
(96) она показывает и блокировки 1с по данным ТЖ, там есть отдельный флаг
   Franchiser
 
98 - 08.05.19 - 11:31
вообще тот файл настроек тж который я редактировал и создала на сервере обработка Бурмистрова
   Cyberhawk
 
99 - 08.05.19 - 11:32
(96) Не, та показывает и упр.
   Feanor
 
100 - 08.05.19 - 11:54
(98) включи руками полный ТЖ, проверь, что есть нужные события
  1  2   

Список тем форума
Рекламное место пустует  Рекламное место пустует
ВНИМАНИЕ! Если вы потеряли окно ввода сообщения, нажмите Ctrl-F5 или Ctrl-R или кнопку "Обновить" в браузере.