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