|
Забавная особенность SQL 2014 + ФИАС+ регион 02= тормоза при поиске улицы | ☑ | ||
---|---|---|---|---|
0
MaximSh
06.05.18
✎
17:03
|
Окружение:
SQL 2014 с SP2 (12.0.5707.0) От версии платформы не зависит. Сейчас 8.3.10.2667 От конфигурации не зависит. Повторяемость БГУ 2, ЗКГУ, самописка на БСП. От свежести данных ФИАС не зависит. Как и от количества загруженных регионов. Должен быть загружен регион 02 Башкортостан Проблема: При вводе первых трех букв улицы в адресе производится поиск. Если в выдаче одна две улицы, то выдача найденных улиц через 12-15 секунд. Если много, то быстро полсекунды. Например, город Йошкар-Ола г, Марий Эл Респ, в поле улице "гск" - выдача быстро, а "вал" 12 секунд. Тормоза по любому региону. В чем прикол: 1) Если удалить регион 02, то все быстро, не зависимо от количества найденных улиц по первым трем буквам. 2) если sql 2017 то тоже все быстро, даже с регионом 02. Rebuild Index, Reorganize Index task, Update Statistics в SQL влияния не оказывают. И как побороть мыслей нет. И почему на скорость запроса влияют данные в базе? |
|||
1
H A D G E H O G s
06.05.18
✎
17:16
|
"И почему на скорость запроса влияют данные в базе?"
Действительно, неожиданный вопрос... |
|||
2
H A D G E H O G s
06.05.18
✎
17:20
|
Там адрес может получаться через Инет по данным сервиса 1С, SQL может быть непричем.
Посмотрите внимательней. |
|||
3
MaximSh
06.05.18
✎
17:30
|
(1) Не количество, а качество. Влияет 02 регион. Если его удалить и загрузить Москву и область (для теста влияния количества, так то не нужны эти регионы), то все быстро.
(2) Настроено, что адресный классификатор из загруженных данных, не из веб-сервиса к 1с во всех трех базах. |
|||
4
H A D G E H O G s
06.05.18
✎
17:31
|
(3) Ну ms sql profiler вам тогда в руки.
|
|||
5
mexanik_96
06.05.18
✎
17:52
|
данные из озу вытесняются на дицк же, то что ищет пол сикенды вероятно находится в памяти, то что дольше на диске идет поднятие страниц очевидно же.
и "выдача найденных улиц" "выдачей" занимается не только сиквел. сначала в (4) там если ок все тогда в рпхост, если не ок, план, железо |
|||
6
MaximSh
06.05.18
✎
17:59
|
||||
7
MaximSh
06.05.18
✎
18:13
|
В результате запроса одна строка, и все затрачиваемое время уходит на ее сортировку.
Запрос (начало улицы "гск" выдает 56 строк и выполняется за 0,205 секунд |
|||
8
MaximSh
06.05.18
✎
18:15
|
(5) не вытесняется, ищу одно и тоже.
|
|||
9
H A D G E H O G s
06.05.18
✎
18:17
|
(7) сделайте mdop=1
|
|||
10
H A D G E H O G s
06.05.18
✎
18:17
|
max degree of parallelism=1 в настройках сервера SQL
|
|||
11
MaximSh
06.05.18
✎
18:26
|
(10) помогло, почитаю за что отвечает. Запросы по подбору улиц выполняются уже за 0,02 сек.
|
|||
12
rphosts
06.05.18
✎
18:34
|
(11) это не могло настолько помочь, максимум вдвое улучшить скорость выполнения. Может статистика устарела? Может базу давно пора сжать?
|
|||
13
rphosts
06.05.18
✎
18:36
|
ТС у тебя ФИАС внутри конфигурации?
|
|||
14
H A D G E H O G s
06.05.18
✎
18:37
|
(12) Чеж не могло то.
Тот момент, когда затраты на ожидания на синхронизацию дороже выигрыша за параллелизм. |
|||
15
MaximSh
06.05.18
✎
18:55
|
(14) большое спасибо за участие. Оставлять 1 вряд ли стоит. Требуется доп тестирование. Больше всего меня поражает влияние именно 02 региона. Мой родной 16. Если загружать в базу 16 и 02 регион— тормоза, если 16 и всех соседей + Москву и область, то быстро.
(13) фиас внутри, обновление статистики неё помогает. Попробую сжать, когда вернусь к компу. |
|||
16
rphosts
06.05.18
✎
19:06
|
(15) и индексы перестрой и отпишись дало это чтото или нет
|
|||
17
MaximSh
06.05.18
✎
19:08
|
(16) Rebuild Index, Reorganize Index task, Update Statistics в SQL влияния не оказывают. Это я сразу проверил. Запускаются по регламенту раз в неделю.
|
|||
18
rphosts
06.05.18
✎
19:14
|
(17) можно просто выгрузить в ДТ и загрузить обратно.... но только перед этим сделать бэкап!
|
|||
19
H A D G E H O G s
06.05.18
✎
19:33
|
(15) Жесть какая.
|
|||
20
Fram
06.05.18
✎
19:36
|
(15) > Оставлять 1 вряд ли стоит.
вообще то это рекомендация из ИТС. Древняя правда статья, но все же |
|||
21
Djelf
06.05.18
✎
19:54
|
А откуда взялся "SQL 2014 с SP2 (12.0.5707.0)"?
Последняя на March 19, 2018 - SQL 2014 с SP2 (12.0.5579.0). https://support.microsoft.com/en-sg/help/2936603/sql-server-2014-build-versions Секретный релиз? |
|||
23
H A D G E H O G s
06.05.18
✎
19:57
|
||||
24
systemstopper
06.05.18
✎
20:08
|
(7) >>В результате запроса одна строка, и все затрачиваемое время уходит на ее сортировку.
с чего ты решил что всё время уходит на сортировку? |
|||
25
systemstopper
06.05.18
✎
20:39
|
(0) покажи duration этого события в профайлере, текст запроса sql и текстовый план
|
|||
26
MaximSh
06.05.18
✎
21:53
|
(12) (18) перезагрузка dt ничего не поменяла.
(21) блин, был древний 12.0.5207.0, автообновление системы проходило (запускал вручную), но конкретно sql с ошибками. Обновил вручную до 12.0.5579.0. Ничего не поменялось. |
|||
27
MaximSh
06.05.18
✎
22:00
|
(25) план здесь https://cloud.mail.ru/public/XFKp/nX7Vp6BFw
cpu 93, reads 1235, writes 1, duration 9598 запрос
|
|||
28
MaximSh
06.05.18
✎
22:14
|
(23)
влияние Max degree of parallelism Оборотно-сальдовая ведомость по счету 105.00 (материальные запасы) за 2017 г. Max degree of parallelism =1. 40 секунд. Max degree of parallelism =0. 30 секунд. Процессор core i5, hyperthreading отключен 4 ядра. Получается нормальные запросы медленней не критично, проблемные - быстрее во много раз (в десятки). |
|||
29
MaximSh
06.05.18
✎
22:18
|
(28) и еще важный момент, пишут, что Max degree of parallelism =1 благоприятно влияет на многопользовательскую работу. до 70 пользователей бывает в 3х базах.
|
|||
30
H A D G E H O G s
06.05.18
✎
22:38
|
(27) Запрос то все равно уежищный.
43000 строк результата в одной из физических операций fld_18482=@P70 Посмотреть на значение P70 и что за измерение fld_18482 в регистре. |
|||
31
H A D G E H O G s
06.05.18
✎
22:40
|
Пардон.
Вот это условие: (T8._Fld18481 = @P69)) AND (T8._Fld18482 = @P70)) |
|||
32
ildary
07.05.18
✎
00:07
|
Простите мой новичковый вопрос - разве сейчас не проще включить онлайн работу с адресами, чтобы снять вопрос скорости работы со скачанными классификаторами, необходимостью регулярного обновления и грустью от раздувания базы?
|
|||
33
rphosts
07.05.18
✎
01:40
|
(29) разумеется, как только кто-то реально тяжелый распараллеливаемый запрос запустил - у остальных возможно подвисание.
|
|||
34
rphosts
07.05.18
✎
02:49
|
исходный запрос можно посмотреть?
|
|||
35
systemstopper
07.05.18
✎
08:55
|
(27) Скуль очень сильно ошибается в оценке кардинальности, на самом верху Est Rows 1 536 920 000 000 при факте в 1 строку.
Происходит на 1-м паралеллизме, Est 2712 Act 113 Причины этого описаны здесь https://www.sqlshack.com/sql-server-top-clause-performance-problem-parallelism/ Плюс many-to-many в merge join это плохо. Плюс top - это row goal, что тоже создает проблемы с оценкой. В итоге одна жиоппа накладывается на другую - ошибаясь с оценкой, данные спиллятся в TempDB, отсюда и тормоза (мое предположение) Решение: We need to eliminate exchange (parallelism) iterator from the query plan, so we will run again the query with maxdop 1 Почему 2017 не тупит если maxdop = 0 - там скорей всего другой план. |
|||
36
systemstopper
07.05.18
✎
08:59
|
(27) +(35) выложи план на 2017
|
|||
37
MaximSh
07.05.18
✎
10:27
|
(34) исходный запрос из БСП подсистема Адресный классификатор: Общий модуль АдресныйКлассификаторСлужебный
Процедура ЗаполнитьСписокАвтоподбораЧастиАдресаВнутр
Параметры конкретного запроса: НачалоСлова "% ЧЕТ%" Строка НачалоФразы "ЧЕТ%" Строка Родитель 93b3df57-4c89-44df-ac42-96f05e9cd3b9 УникальныйИдентификатор Уровни Массив 7,90,91 |
|||
38
MaximSh
07.05.18
✎
10:36
|
(36) план в SQL 2017 14.0.1000.169
https://cloud.mail.ru/public/9aqj/wtBTuLEC5 |
|||
39
systemstopper
07.05.18
✎
10:47
|
(38) Ты не тот план выложил. Нужно не топ 300, а топ 20
|
|||
40
systemstopper
07.05.18
✎
10:49
|
он после выполняется
|
|||
41
MaximSh
07.05.18
✎
10:52
|
(39) точно, https://cloud.mail.ru/public/711J/EFa1qR8Ub
|
|||
42
systemstopper
07.05.18
✎
11:03
|
(41) Так у тебя DOP = 1 на 2017. И везде Act = Est = 1. Всё пучком.
|
|||
43
systemstopper
07.05.18
✎
11:05
|
+(42) Поставь DOP=1 на 2014 и выложи план
|
|||
44
MaximSh
07.05.18
✎
11:06
|
(42) ха, а в настройках SQL 2017 Максимальная степень параллелизма =0
|
|||
45
systemstopper
07.05.18
✎
11:10
|
(44) Но выполнился он с DOP = 1
CardinalityEstimationModelVersion="140"> <QueryPlan DegreeOfParallelism="1" |
|||
46
MaximSh
07.05.18
✎
11:20
|
(43) https://cloud.mail.ru/public/8Tor/pkzsXpb37
план в SQL 2014 c MDOP=1 по сути варианты решения 1) оставить MDOP=1 в SQL 2014 2) очистить регион 02 из классификатора 3) перейти на SQL 2017 |
|||
47
systemstopper
07.05.18
✎
11:22
|
(46) Сколько cost threshold for parallelism для 2014 и 2017?
|
|||
48
systemstopper
07.05.18
✎
11:23
|
(46) Что-то не то ты выложил. Выложи в Sqlplan, как предыдущие планы
|
|||
49
MaximSh
07.05.18
✎
11:27
|
||||
50
MaximSh
07.05.18
✎
11:30
|
(47) одинаков и равен 5
|
|||
51
systemstopper
07.05.18
✎
11:34
|
(50) У тебя на 2017 параллелизм не задействовался, потому что стоимость запроса посчитал 0.44, а на 2014 109609000
|
|||
52
systemstopper
07.05.18
✎
11:48
|
(50) На 2014 так же лажается с оценкой кардинальности при DOP = 1. Поэтому и стоимость считает высокой и включает параллелизм. В чем причина - хз. Может в том что включает merge join many-to-many в 3-х соединениях, а на 2017 там Nested Loops. Но при DOP = 1 не спулит в tempdb, может за счет это быстрее.
Похоже на глюк скуля. На 2014 все сервис-паки и апдейты поставлены? Лучше конечно на 2016 перейти, 2017 официально не поддерживается. |
|||
53
systemstopper
07.05.18
✎
11:52
|
В 2017 ввели адаптивную оптимизацию запросов и много других улучшений. Но мне кажется что и 2016 не будет тупить с оценкой.
|
|||
54
MaximSh
07.05.18
✎
14:09
|
(52) SQL 2014 последний билд.
Спасибо, перейду на 2016. |
|||
55
H A D G E H O G s
07.05.18
✎
14:20
|
Меня вот одно интересует - это типовая шняга?
|
|||
56
timurhv
07.05.18
✎
20:24
|
(55) Не скажу что это 100% ответ на данную проблему, информация с ИТС:
https://its.1c.ru/db/metod8dev#content:5904:hdoc |
|||
57
timurhv
07.05.18
✎
20:26
|
+ (56) Я лично сразу включал флаги трассировки:
-T4199 -T1118 Падения не наблюдал, сравнивать не с чем. |
|||
58
Tateossian
07.05.18
✎
20:48
|
(46) 1С в процессе работы меняет MAXDOP в хинтах оптимизатору, лично были такие замечены:
WITH(NOLOCK) WITH(TABLOCK) | FAST 1 | FORCE ORDER | MAXDOP Поэтому, нет особо смысла менять, 1С указания дает дополнительно. |
|||
59
systemstopper
07.05.18
✎
20:54
|
(58) ЛОЛ, и какие же указания дало это ваше 1С когда данные при паралеллизме начали спилиться в темпдб?)))
|
|||
60
MaximSh
09.05.18
✎
09:14
|
SQL 2016 build последний 13.0.5026.0 при MDOP=0 также все плохо, 11,5 сек выполнение запроса поиска улицы про первым трем буквам "dfk". В результате 0 строк.
план: https://cloud.mail.ru/public/7Mr7/uEGgHiEBx Если искать "гск", в результате 20 строк за 0,036 сек В работе оставил MDOP=1 Когда 1С заявит совместимость с SQL 2017 проверю что стало там. |
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |