Имя: Пароль:
1C
1С v8
Как оценить производительность сервера 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
Анализ ключевых показателей производительности
https://msdn.microsoft.com/ru-ru/mt631603.aspx
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
а кратковременная очередь вообще ни о чем не говорит