|
Как оценить производительность сервера MSSQL? | ☑ | ||
---|---|---|---|---|
0
kgbplus
24.11.16
✎
12:16
|
Есть большая база УТ и в ней есть документ, который долго проводится (45 секунд). Долго разбираемся почему.
Выяснено, что виноват типовой запрос по партиям. Выполняется 15 секунд. Видимо есть еще какие то тормозные. Если отключить партионный учет, то весь документ проводится за 8 секунд. Переходим к части "что делать?": Прогнали ТиИ, пересчитали статистику на сервере SQL, обновили платформу. Результата нет. Запустили Perfomance monitor, накопили данных, поглядели. Ну в момент обработки документа подрастает очередь диска до 10. Судя по всему это не ужас. Процессор ничем не занят, памяти полно. Поставили ЦУП. Поглядели там, увидели этот самый запрос, ничего другого не увидели. Блокировок и таймаутов нету. Запустили MS SQL Profiler. Видим снова этот запрос (15 с лишним тысяч миллисекунд выполнения, 1.5 млн чтений), остальное время куча маленьких запросов. Возникает предположение, что медленно работает MSSQL. Известно, что какое то время назад работал нормально. То ли база выросла, то ли что то сломалось. Надо понять. Железо сервера не самое современное, но и не древнее. То ли менять, то ли нет. SSD диски конечно поставим, но все равно надо понять, что стряслось. Погоняли тест Гилева. Что то показывает. Толком непонятно что. Видно, что на рабочей станции в связке с SQL express работает быстрее (но на той же самой связке указанный документ проводится еще дольше!!!). Внимание, вопрос - как понять тормозит MSSQL или нет? Существуют ли какие то бенчмарки именно для сервера? Почему он так долго выполняет этот запрос (косой, кривой, неправильно написанный, 18 вложенных циклов и т.п.), при том, что другие инструменты страшной нагрузки не показывают? Как говорится - чего стоим, кого ждем? |
|||
1
yfylhjkjy
24.11.16
✎
12:24
|
План запроса покури, на что именно идут 15 секунд.. и оптимизируй наздоровье
|
|||
2
pavlika
24.11.16
✎
12:27
|
||||
3
Fragster
гуру
24.11.16
✎
12:29
|
типовой запрос по партиям начинает работать в 5 раз быстрее простым выносом виртуальных таблиц во временные. а вообще его можно раз в 15 заставить быстрее работать.
|
|||
4
kgbplus
24.11.16
✎
12:31
|
(1) С запросом все понятно. Но вдруг это сервер тормозит, надо же разобраться
|
|||
5
Вафель
24.11.16
✎
12:31
|
(3) типовой запрос в какой конфе?
|
|||
6
kgbplus
24.11.16
✎
12:32
|
(2) Это я видел, но я не пойму, что с сервером не так. Разве очередь к диску 10 (в чем они ее измеряют?) это много? Я читал, что тормозить начинает после 20-30.
|
|||
7
kgbplus
24.11.16
✎
12:33
|
(3) Да, это обязательно сделаем! Вообще 1С загадка - сами пишут в книгах не делать соединения с вложенными запросами и виртуальными таблицами и сами же делают в типовых конфах!
|
|||
8
Вафель
24.11.16
✎
12:33
|
план запроса смотрел?
|
|||
9
Вафель
24.11.16
✎
12:34
|
(7) А если бы на постгре такое было, то вообще бы не дождался ответа )))
|
|||
10
kgbplus
24.11.16
✎
12:34
|
(5) в УТ 10.3
|
|||
11
kgbplus
24.11.16
✎
12:35
|
(8) видел. 18 вложенных циклов, пипец, считать устал. Но вопрос у меня все таки как понять тормозит MSSQL или нет?
|
|||
13
Fragster
гуру
24.11.16
✎
12:36
|
(5) угадай с одного раза, про какой запрос я горворю
|
|||
14
Fragster
гуру
24.11.16
✎
12:36
|
(7) многие вещи в типовых тянутся с 8.0, когда временных таблиц еще не было
|
|||
15
kgbplus
24.11.16
✎
12:36
|
(9) На постгре я бы сам наверное быстрее разобрался. Кстати интересная мысль - поставить на тот же самый сервер постгре и сравнить производительность той же базы на нем!
|
|||
16
Fragster
гуру
24.11.16
✎
12:37
|
(11) тормозят 1.5 млн чтений
|
|||
17
Вафель
24.11.16
✎
12:37
|
(15) Постгре воообще не любит соединения с подзапросами, прям кровь из носу
|
|||
18
Вафель
24.11.16
✎
12:39
|
а может РЛС еще действует?
|
|||
19
kgbplus
24.11.16
✎
12:39
|
(17) Говорят только внешние соединения не любит, с остальными все как у MSSQL. Но сам не проводил экспериментов.
|
|||
20
kgbplus
24.11.16
✎
12:41
|
(16) ну дык получается - поставим SSD, вынесем базу и tempdb на него и все наладится? Иначе каждый запрос надо руками исправлять. Я и хочу это заранее понять, в идеале, не покупая SSD
|
|||
21
Fragster
гуру
24.11.16
✎
12:43
|
(20) там таких запросов всего несколько, исправив которые всё станет лучше.
|
|||
22
Fragster
гуру
24.11.16
✎
12:43
|
а ставить ssd не надо
|
|||
23
vde69
24.11.16
✎
12:43
|
||||
24
Вафель
24.11.16
✎
12:43
|
переходи на отложенное проведение по партиям
|
|||
25
Вафель
24.11.16
✎
12:44
|
(23) По цупу уже проверяли блокировки же
|
|||
26
H A D G E H O G s
24.11.16
✎
12:44
|
(20) 2 запроса там. На упр и бух учет.
|
|||
27
kgbplus
24.11.16
✎
12:44
|
(18) RLS? она влияет на производительность? но у нас нет такого
|
|||
28
Fragster
гуру
24.11.16
✎
12:45
|
(26) это в УПП, в УТ один, наверное
|
|||
29
kgbplus
24.11.16
✎
12:45
|
(21) так скорее всего и сделаю, спасибо!
|
|||
30
kgbplus
24.11.16
✎
12:46
|
(24) да, тоже реализуем такое, но у нас пользователи крик подняли, что хотят иметь документы сразу. Будем делать и так и так. Отложенное уже написано, а запросы поправить быстро
|
|||
31
vde69
24.11.16
✎
12:47
|
ну и как всегда вопрос: обновление статистики на SQL настроено?
|
|||
32
kgbplus
24.11.16
✎
12:48
|
(23) хм, спасибо. Но там скорее всего не в блокировках дело. Я проверял даже когда ночью никого нет, время проведения от этого почти не зависит. Там тупо много чтения и вложенных циклов, хочется понять, может быть можно как то сервер заставить выполнять запрос побыстрее.
|
|||
33
kgbplus
24.11.16
✎
12:48
|
(31) с этого начали. Каждую ночь пересчитываем
|
|||
34
vde69
24.11.16
✎
12:48
|
>>>Ну в момент обработки документа подрастает очередь диска до 10.
это ЖЕСТЬ !!! очередь к диску не должна быть более 1 |
|||
35
kgbplus
24.11.16
✎
12:49
|
(34) О! Это интересно. Т.е. получается проблема в тормозном диске?
|
|||
36
Fragster
гуру
24.11.16
✎
12:50
|
(35) нет
|
|||
37
МешочекЗнаний
24.11.16
✎
12:51
|
(35) в 1.5 млн чтений
|
|||
38
kgbplus
24.11.16
✎
12:51
|
(36) ну в смысле, если предположить, что запросы оптимизировали
|
|||
39
Fragster
гуру
24.11.16
✎
12:52
|
(34) кто тебе такое сказал? может, для десктопного диска wd green так и должно быть, а для нормального рэйда или СХД это вполне может быть нормой.
в данном случае так параллелизм скуляки отрабатывает, скорее всего (даже если его в плане нет) |
|||
40
Вафель
24.11.16
✎
12:52
|
(38) Ключевой момент в том что подскакивает.
Если бы постоянно было, то да мощности диска не хватает |
|||
41
vde69
24.11.16
✎
12:52
|
(35)не обязательно именно в нем корень проблемы, но переход на быстрые диски гарантировано очень сильно уменьшат проблему...
сделайте (23) при работающей системе (когда все работают и проводят доки) и выложите результаты сюда, тогда будет понятно |
|||
42
Вафель
24.11.16
✎
12:52
|
а кстати может парараллельность отключить?
|
|||
43
kgbplus
24.11.16
✎
12:53
|
(40) нет, это вообще только в момент этого самого запроса происходит, остальное время меньше 1
|
|||
44
Fragster
гуру
24.11.16
✎
12:53
|
(41) проблема. в. запросе.
|
|||
45
Dotoshin
24.11.16
✎
12:54
|
(0) Тут вот Как быстро найти неоптимальности в запросе (волшебная консоль запросов)
предлагали потестить всякие запросы, может еще можно забесплатно ваш запрос, который тормозит, проанализировать... |
|||
46
Вафель
24.11.16
✎
12:54
|
(43) вот видишь - значит хватает мощности то
|
|||
47
Вафель
24.11.16
✎
12:54
|
(44) Всегда можно экстенсивным путем уменьшить проблему
|
|||
48
Fragster
гуру
24.11.16
✎
12:54
|
(45) что там тестить? оно покажет - вынесите виртуальные таблицы во временные.
|
|||
49
kgbplus
24.11.16
✎
12:55
|
(42) макс. параллелизм 1 стоит, специально еще раз проверил. Вообще все по списку тюнинга MSSQL проверял первым делом
|
|||
50
vde69
24.11.16
✎
12:55
|
(39) замечено экспериментально (на разных серверах, и новых и стрых и ссд и 15тыс ), при очереди 5 наступает дикий тупняк 1с
|
|||
51
Fragster
гуру
24.11.16
✎
12:56
|
(50) у меня не наступает
|
|||
52
kgbplus
24.11.16
✎
12:56
|
(45) да с запросом все понятно, там куча соединений с вложенными запросами, так делать не хорошо
|
|||
53
Fragster
гуру
24.11.16
✎
12:57
|
(50)+ да и вообще тебе пишут - проверяли ночью с неработающими пользователями - разницы нет.
|
|||
54
kgbplus
24.11.16
✎
12:57
|
(46) так меня это и удивляет. Причем на этом же MSSQL лежит еще бухгалтерская база (сервер 1с стоит на другом серваке), бухи не жалуются вообще никогда на производительность.
|
|||
55
kgbplus
24.11.16
✎
12:58
|
(48) да, это вопрос решенный, сейчас займусь
|
|||
56
vde69
24.11.16
✎
12:59
|
(44) скорее всего причина действительно в запросе (плюс рельсе), но ее вполне можно прибить и железом.... тут как говорится "есть нюансы"...
а возможно например причина в наличии одного документа в будущей дате, и тогда режим проведения всегда "неоперативный", а ведь при оперативном режиме проведение ЛЕТАЕТ !!! |
|||
57
Fragster
гуру
24.11.16
✎
13:00
|
(56) в 20 раз ты диски не увеличишь
|
|||
58
kgbplus
24.11.16
✎
13:00
|
Ладно, всем спасибо! Я вроде понял, что делать дальше, похоже сервер тут не причем, это радует. Но SSD уже заказал, пусть будут )
|
|||
59
Fragster
гуру
24.11.16
✎
13:00
|
(58) отправь мне один
|
|||
60
vde69
24.11.16
✎
13:04
|
(58) у нас купили сервак с ссд, хороший и дорогой....
поставили базы - через месяц пошли отказы дисков, сейчас поменяли на обычные.... диски - на экспертизу, она выясняла - диски нормальные но вот райд контроллер чудит не по детски... так, что диски - они такие :))) я на этом потратил не один день подлечивая базы после всего этого.... |
|||
61
Demiurg
24.11.16
✎
13:06
|
(0) если не разберетесь, можем бесплатно сделать аудит http://www.gilev.ru/audit/
|
|||
62
kgbplus
24.11.16
✎
13:07
|
(60) ну вроде не самые дешевые заказал, intel s3700. Продавец клянется, что пока еще обратно не приносили.
Можно на них сначала tempdb только положить, посмотреть что будет |
|||
63
Ты чо в натуре
24.11.16
✎
13:08
|
(60) (62) Вроде не советуют ССД в райд ставить...
|
|||
64
kgbplus
24.11.16
✎
13:09
|
(63) а в чем могут быть проблемы? зеркало просто - читать быстрее будет
|
|||
65
vde69
24.11.16
✎
13:15
|
(63) практически на всех хостингах ссд в райдах...
вообще для ссд замечателен 50 райд из 8 дисков, просто улет как работает... (62) контроллер может быть не совместимым :) |
|||
66
kgbplus
24.11.16
✎
13:17
|
(65) Ну посмотрим. Всегда есть вариант программного райда. Вообще, есть мнение, что аппаратные райды это атавизм времен слабых процессоров. Что на современных серверах они ничего не дают.
|
|||
67
Ты чо в натуре
24.11.16
✎
13:27
|
(64) хз почему, но Андрей Бурмистров из команды gilev.ru говорит что наблюдают такую закономерность - падает скорость
|
|||
68
ildary
25.11.16
✎
16:12
|
(56) а можно уточнить - документ в будущем должен быть проведен или достаточно его наличия, чтобы включился неоперативный режим?
|
|||
69
kgbplus
08.12.16
✎
11:58
|
Кому интересно, докладываю результат:
1. Установкой SSD достигнуто ускорение с 15 до 14.5 секунд на этом запросе. Единственное объяснение, которое удалось придумать - райд из 4-х САС дисков достаточно быстр сам по себе. 2. Переносом вложенного запроса во временную таблицу достигнуто ускорение с 15 до 1 секунды. (делалось до установки SSD) 3. Отложенное проведение написано и внедрено, все щасливы. Собственно всем еще раз огромное спасибо за советы! |
|||
70
Fragster
гуру
08.12.16
✎
12:00
|
(69) т.е. информация в (3) была абсолютно верной (в т.ч. про "в 15 раз")
|
|||
71
kgbplus
08.12.16
✎
12:13
|
(70) Абсолютно точно
|
|||
72
Fragster
гуру
08.12.16
✎
12:24
|
(71) а что насчет (59)?
|
|||
73
kgbplus
08.12.16
✎
12:30
|
(72) Как в анекдоте, хотел отправить 100$ но уже заклеил конверт ;-)
|
|||
74
trdm
08.12.16
✎
12:32
|
(0) > Есть большая база УТ и в ней есть документ, который долго проводится (45 секунд). Долго разбираемся почему.
Выяснено, что виноват типовой запрос по партиям. Выполняется 15 секунд. Видимо есть еще какие то тормозные. Если отключить партионный учет, то весь документ проводится за 8 секунд. Да вы охренели ТАК РАБОТАТЬ. Если бы у меня так документы проводились бы я бы застрелился наверное. |
|||
75
kgbplus
08.12.16
✎
12:34
|
(74) Мы были близки к этому, но решили напоследок попробовать что то изменить
|
|||
76
IlyaSR
08.12.16
✎
12:41
|
(74) Документ документу рознь, не понятно какие проверки сделаны и по скольким регистрам, а также кол-во строк ТЧ.
|
|||
77
IlyaSR
08.12.16
✎
12:44
|
(76) + можно воспользоваться http://catalog.mista.ru/public/173394/
|
|||
78
Это_mike
08.12.16
✎
12:54
|
(74) а я б не успел....
|
|||
79
kossmatiy
08.12.16
✎
13:14
|
(6) не более 2*кол-во дисков
|
|||
80
Fragster
гуру
08.12.16
✎
14:35
|
(79) -> (39)
|
|||
81
Лефмихалыч
08.12.16
✎
14:37
|
||||
82
Fragster
гуру
08.12.16
✎
14:47
|
вот например: https://technet.microsoft.com/ru-ru/library/dn894707(v=ws.11).aspx#BKMK_SequentialIOTests на картинке максимальная производительность на глубине очереди 4*количество дисков
|
|||
83
Fragster
гуру
08.12.16
✎
14:47
|
а кратковременная очередь вообще ни о чем не говорит
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |