Имя: Пароль:
1C
 
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) там нетранзакционное чтение, он явно это написал
Здесь можно обсудить любую тему при этом оставаясь на форуме для 1Сников, который нужен для работы. Ymryn