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

1C+MSSQL+PAGELATCH_EX

1C+MSSQL+PAGELATCH_EX
Я
   Мистикан
 
03.07.20 - 17:06
Для 1С не подходят решения с помощью увеличения длины первичного ключа кластерного индекса. Есть какие либо другие решения?
   H A D G E H O G s
 
1 - 03.07.20 - 18:02
Шта?
   Бовка
 
2 - 03.07.20 - 18:08
(0) а зачем понадобилось длину PK увеличивать?
   nicxxx
 
3 - 03.07.20 - 19:41
(0) У вас 40 потоков пишут в одну таблицу? Приветствую, коллега по несчастью:) Битва за последнюю страницу идет страшная :)
Кластерный индекс там - модифицированный ГУИД, как вы собрались его увеличивать? Если, конечно, я правильно догадался, что запись выполняется в документ или справочник.
   Мистикан
 
4 - 04.07.20 - 08:29
(3) основная конкуренция за партии товаров+продажи себестоимость ((( есть большой механизм расчета закупок который постоянно юзает эти регистры на чтение+ 4-5 чеков проводится в секунду+ну и основной документооборот (
   Мистикан
 
5 - 04.07.20 - 08:30
(3) пишут причем где то 10-15... а вот читают еще от 40 до 100 в это время (
   Мистикан
 
6 - 04.07.20 - 08:39
(3) не собираюсь... думаю что еще можно сделать... когда снижали avg stall темпдб с 4 дисков и 8 файлов вынесли на 1 файл и 1 диск. Думаю сегодня попробовать 2 диска/2 файла по идее это должно уменьшить ожидание буфера
   Мистикан
 
7 - 04.07.20 - 08:45
(2) увеличение длины ключа приводить к увеличению количества страниц индекса и снижает конкуренцию за последние страницы
   vi0
 
8 - 04.07.20 - 09:34
почему ты постоянно упоминаешь чтение?
   vi0
 
9 - 04.07.20 - 09:44
сделай явное назначение УИДа через конструктор уида для первой ссылки индекса, чтобы увеличить разброс
   Мистикан
 
10 - 04.07.20 - 10:18
(8) вообще то уровень изоляции SERIALIZABLE конкурирует со вставкой... если много читают, INSERT будет ждать своей очереди.
   vi0
 
11 - 04.07.20 - 10:19
(10) ты только о чтениях в транзакции?
   Мистикан
 
12 - 04.07.20 - 10:21
и как раз должны возникнуть ожидания PAGELATCH_EX и PAGELATCH_SH, как я понял, если чтение идет через покрывающий индекс... у нас почти все тяжелые чтения оптимизированы чтобы попадали в кластерный, даже если есть некоторая избыточность
   Мистикан
 
13 - 04.07.20 - 10:21
ну и изменения последние после которых началась проблема на эти мысли подвигли
   vi0
 
14 - 04.07.20 - 10:27
(10) мне так кажется, здесь ты говоришь про блокировки типа lock, не latch
   Мистикан
 
15 - 04.07.20 - 10:34
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    PAGELATCH_EX    Buffer Latch    1102.5    0.3    59.9    5.4    74112    14.9
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    PAGELATCH_SH    Buffer Latch    883.1    0.2    55.2    6.3    65660    13.4
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    SOS_SCHEDULER_YIELD    CPU    195.6    0.1    195.2    99.8    345406    0.6
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    CXPACKET    Parallelism    32.9    0.0    4.5    13.7    5680    5.8
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    LCK_M_RS_U    Lock    32.1    0.0    0.0    0.0    15    2143.1
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    ASYNC_NETWORK_IO    Network IO    17.9    0.0    15.6    87.2    27351    0.7
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    LCK_M_IX    Lock    12.9    0.0    0.0    0.0    4    3215.5
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    PAGEIOLATCH_SH    Buffer IO    6.9    0.0    0.0    0.0    1073    6.4
   Мистикан
 
16 - 04.07.20 - 10:36
тут и чтение и эксклюзивный доступ к странице. Я пытаюсь в голове укрупнить до уровня кода и запросов которые могут создать такую ситуацию
   Мистикан
 
17 - 04.07.20 - 10:42
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    LCK_M_RS_U    Lock    32.1    0.0    0.0    0.0    15    2143.1
WAIT STATS    2020-07-03 10:09:21.3709156 +03:00    300    LCK_M_IX    Lock    12.9    0.0    0.0    0.0    4    3215.5

конкуренция за страницы уменьшила ожидания блокировок lock, они должны быть выше
   vi0
 
18 - 04.07.20 - 10:56
так ты не ответил - чтения ты говоришь о чтениях в транзакции?
   vi0
 
19 - 04.07.20 - 10:56
с блокировками lock?
   vi0
 
20 - 04.07.20 - 10:58
для начала надо понять какую прикладную проблему мы решаем
   Мистикан
 
21 - 04.07.20 - 10:59
(18) основная проблема чтения вне транзакции
   Мистикан
 
22 - 04.07.20 - 11:06
(20) есть километровые запросы которые с начала прошлой недели стали выполняться в 5 раз дольше. Сначала я залез в эти запросы и там оказалось что данные в некоторых подзапросах читались прямо с физических таблиц, отборы накладывая через WHERE. читаем 30М строк, возвращаем 400к, в вложенном запросе. Вынес во временные, через виртуальную таблицу. Началась эта свистопляска под большой нагрузкой
   vi0
 
23 - 04.07.20 - 11:10
была проблема 1, после доработок возникла проблема 2
но мы же своими руками создали вторую проблему
может быть запросы оптимизировать более корректно?
   H A D G E H O G s
 
24 - 04.07.20 - 11:11
Я один тут нихера не понимаю?

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

Ну и о каких блокировках речь при грязном чтении (чтении вне транзакции) ?
   H A D G E H O G s
 
25 - 04.07.20 - 11:13
(10) А у вас автоматические блокировки 1С, если речь про SERIALIZABLE  ?
   vi0
 
26 - 04.07.20 - 11:14
(23) хотя я бы начал с того, чтобы понять почему именно с прошлой недели возникли проблемы
   Мистикан
 
27 - 04.07.20 - 11:15
(25) да... в связи с некоторыми "решениями" в следствии которых когда то отказались от измения Склад в регистре Партии на складах, даже смысла не вижу на управляемые переходить... все равно эскалация будет на всю таблицу партий по номенклатуре
   H A D G E H O G s
 
28 - 04.07.20 - 11:17
(26) У меня такая же херота была.
Нормально типовой запрос работал, по расчету взаиморасчетов в УТ11.2, потом в один прекрасный день встал просто колом.
План запроса показывал crossjoin таблицы движений по взаиморасчетам с таблицей остатков, хотя так быть не должно.
Переписал на 2 временные таблицы.
   H A D G E H O G s
 
29 - 04.07.20 - 11:17
(27) Что за конфа то?
   Мистикан
 
30 - 04.07.20 - 11:18
(26) недавно накинули несколько нахлебников. Интернет магазин и статистику собирают по продажам. Больше ничего крупного не было. +увеличилось количество категорийных менеджеров которые работают с этим БП
 
 Рекламное место пустует
   Мистикан
 
31 - 04.07.20 - 11:19
(28) ну вот я переписал.. план стал красивый. И тут здрасте... а мы буфер ждем теперь
   vi0
 
32 - 04.07.20 - 11:20
(24) "Но кластер регистра - он случаен"
кластерный индекс основной таблицы регистра накопления: [ОРРХ | ОРНР1 +] Период + Регистратор + НомерСтроки
   H A D G E H O G s
 
33 - 04.07.20 - 11:20
(31) Волшебный mdop равен 1 ?
   Мистикан
 
34 - 04.07.20 - 11:21
(29) УТ10.2 для украины. Но от типовой там нифига. Ее превратили в подобие Комплексной, впилив туда план счетов с регистром бухгалтерии
   Мистикан
 
35 - 04.07.20 - 11:21
(33) да
   H A D G E H O G s
 
36 - 04.07.20 - 11:21
(32) Да, пардон, про таблицу движений чет забыл.
   Мистикан
 
37 - 04.07.20 - 11:24
(33) ночью переключаем, когда параллельность минимальная для регламентов. Утром обратно
   Мистикан
 
38 - 04.07.20 - 11:27
попробую увеличить количество темпдб до 2 и в понедельник под нагрузкой сделаю замеры
   Мистикан
 
39 - 04.07.20 - 11:29
пока больше ничего в голову не приходит как это лечить (
   Мистикан
 
40 - 04.07.20 - 11:34
Кстати. Вопрос. Когда индексируем временную таблицу, индекс с нуля создается или субд его с кластерного собирает?
   H A D G E H O G s
 
41 - 04.07.20 - 11:55
(9) Как, кстати, это может помочь?
Новый УникальныйИдентификатор() всегда же будет больше любого предыдущего и постучит в последнюю страницу.
Ну и если вставка не в последнюю страницу - тоже такое себе решение, грозящее расщеплением.
   H A D G E H O G s
 
42 - 04.07.20 - 11:56
(32) Нужно просто больше строк в документе!
   vi0
 
43 - 04.07.20 - 11:58
(41) покажи на примере что будет больше последующего
   vi0
 
44 - 04.07.20 - 11:58
(40) я не понял вопрос
   H A D G E H O G s
 
45 - 04.07.20 - 12:01
(43) Это было предположение. Он не будет больше?
   vi0
 
46 - 04.07.20 - 12:05
(45) ну, фраза не выглядит как предположение)
насколько я знаю такие уиды не последовательные
   Мистикан
 
47 - 04.07.20 - 12:10
(44) когда индексируем временную таблицу в запросе, как субд создает непосредственный индекс?
   H A D G E H O G s
 
48 - 04.07.20 - 12:10
(46) непоследовптельные- да. Но почти  наверняка увеличивающиеся. Ибо в них как минимум зашит день создания.
   H A D G E H O G s
 
49 - 04.07.20 - 12:11
(47) create index
А какие еще способы есть то?
   vi0
 
50 - 04.07.20 - 12:17
(48) это тоже предположение? или есть пример?
   vi0
 
51 - 04.07.20 - 12:18
(47) посмотри в профайлере
   vi0
 
52 - 04.07.20 - 12:18
(48) "непоследовптельные- да. Но почти  наверняка увеличивающиеся"
сам себе противоречишь
   Йохохо
 
53 - 04.07.20 - 12:39
(52) нет, посмотри на смысл групп символов в уид
   vi0
 
54 - 04.07.20 - 12:52
(53) фраза противоречивая - неполедовательные, но увеличивающиеся
   acht
 
55 - 04.07.20 - 12:53
(54) числа 1 2 4 8 16 - непоследовательные. Увеличивающиеся.
   vi0
 
56 - 04.07.20 - 12:54
(55) ладно, согласен
   vi0
 
57 - 04.07.20 - 12:54
(53) покажи мне эти группы символов, созданные конструктором уид
   Йохохо
 
58 - 04.07.20 - 13:13
(57) сам погугли, там есть сессионная часть
   H A D G E H O G s
 
59 - 04.07.20 - 13:31
   vi0
 
60 - 04.07.20 - 13:43
(59) ну и где там конструктор?
 
 Рекламное место пустует
   Йохохо
 
61 - 04.07.20 - 13:51
(60) у тебя яндекс да?)
   pechkin
 
62 - 04.07.20 - 14:01
а нельзя к индексу добавить поле рэндом?
все равно уже ломаем по самоп небалуйся
   vi0
 
63 - 04.07.20 - 14:16
(62) именно это я предложил в (9), но видимо местные не знают что такое конструктор уида
но, судя по дискуссии, там скорее проблема комплексная
   1CnikPetya
 
64 - 05.07.20 - 01:16
(4) Есть причины, по которым эти все считается в онлайне?
   rphosts
 
65 - 05.07.20 - 07:27
(0) Ээээээ, версионник (даже ваш сиквел последних версий умеет прикидываться версионником) не спасёт отца русской демократии?
   rphosts
 
66 - 05.07.20 - 07:28
(64) думаю точную себестоимость ет никаких причин считать онлайн... думаю в период минимальной нагрузки реально устроить пересчёт за последние сутки... но если так пригорает - считать онлайн приближенную себестоимость
   rphosts
 
67 - 05.07.20 - 07:29
(62) нахрена рэндом искать - время разбазаривать если есть № коннекта/№ сеанса и т.п.
   rphosts
 
68 - 05.07.20 - 07:31
+ (65) таки да, версионник + разделение итогов
   vi0
 
69 - 05.07.20 - 09:57
(68) судя по (22) у него проблема в чтении, не в записи
   vi0
 
70 - 05.07.20 - 10:01
(67) не понял про "время разбазаривать"
но соглашусь что рандом вероятно там не нужен, нужен глубокий анализ проблемы, и возможно не в вообще индексе там дело
   rphosts
 
71 - 05.07.20 - 11:23
(70) получить рандом если оно не на уровне материнки - трата времени, если есть особые требования, например гарантированная уникальность 1Е9 значений за какой-то период времени - это может быть довольно затратно.
   vi0
 
72 - 05.07.20 - 11:40
(71) все имеет свою цену, особенно если говорить про миллиарды
вопрос применимости к конкретному кейсу
   H A D G E H O G s
 
73 - 05.07.20 - 12:24
Какой версионник? У автора - автомат, а это seriasable на регистрах и repeatable read на обьектных.
Ему хотя бы в управляемые вылезти.
   rphosts
 
74 - 05.07.20 - 19:45
(73) ну тогда перевод на управляемые - первый шаг.... и скорее всего этого и хватит. Версионник на авт - зло!
   vi0
 
75 - 05.07.20 - 20:35
(74) прикольный совет, с учетом того что конкретно не ясно в чем там дело
и особенно с учетом того что это нетривиальная задача
   rphosts
 
76 - 06.07.20 - 01:54
(75) перевод авт. на упр. нетривиальная задача?
   vi0
 
77 - 06.07.20 - 08:51
(76) да
   ДенисЧ
 
78 - 06.07.20 - 08:57
(76) Переведи на управляемые расчёт себестоимости в типовой УПП...
   pechkin
 
79 - 06.07.20 - 09:09
заблокировал все по организации и готово
   fisher
 
80 - 06.07.20 - 09:19
(75) Нормальный совет. У ТС проблемы с транзакционным чтением. Версионник решит эту проблему на корню. Т.е. банальный переход на упр-блокировки.
   fisher
 
81 - 06.07.20 - 09:24
(21) Чтение вне транзакции на авто-транзакциях в блокировочнике - грязное. Его ничего не может блокировать, кроме изменения схемы.
   fisher
 
82 - 06.07.20 - 09:29
Тут просто некоторая путаница упр/авто и блокировочник/версионник. На современном сиквеле включение упр-блокировок автоматически заюзывает режим версионника в mssql.
Но что происходит в смешанном режиме, когда параллельно используются и автоматические и управляемые транзакции - для меня вопрос. Если кто в курсе - расскажите.
   rphosts
 
83 - 06.07.20 - 10:05
(78) ну свою нетленку перевёл... никаких особых проблем... так давно что уже забыл когда было. Зачем расчёт себестоимости переводить если есть ЕРП? Потом, разве нельзя сделать частичный перевод(режим управления блокировкой = Упр+авт и понемногу переводить)?
   rphosts
 
84 - 06.07.20 - 10:09
(82) Если для конфигурации выбрано значение «Автоматический» или «Управляемый», то режим, установленный для объектов, будет игнорироваться. Если у конфигурации выбран смешанный режим
«Автоматический и управляемый», то будет использоваться тот режим, который указан для объекта метаданных, открывшего транзакцию.
   vi0
 
85 - 06.07.20 - 10:09
(80) там нетранзакционное чтение, он явно это написал


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