Есть большая база УТ и в ней есть документ, который долго проводится (45 секунд). Долго разбираемся почему.
Выяснено, что виноват типовой запрос по партиям. Выполняется 15 секунд. Видимо есть еще какие то тормозные. Если отключить партионный учет, то весь документ проводится за 8 секунд.
Переходим к части "что делать?":
Прогнали ТиИ, пересчитали статистику на сервере SQL, обновили платформу. Результата нет.
Запустили Perfomance monitor, накопили данных, поглядели. Ну в момент обработки документа подрастает очередь диска до 10. Судя по всему это не ужас. Процессор ничем не занят, памяти полно.
Поставили ЦУП. Поглядели там, увидели этот самый запрос, ничего другого не увидели. Блокировок и таймаутов нету.
Запустили MS SQL Profiler. Видим снова этот запрос (15 с лишним тысяч миллисекунд выполнения, 1.5 млн чтений), остальное время куча маленьких запросов.
Возникает предположение, что медленно работает MSSQL. Известно, что какое то время назад работал нормально. То ли база выросла, то ли что то сломалось. Надо понять.
Железо сервера не самое современное, но и не древнее. То ли менять, то ли нет. SSD диски конечно поставим, но все равно надо понять, что стряслось.
Погоняли тест Гилева. Что то показывает. Толком непонятно что.
Видно, что на рабочей станции в связке с SQL express работает быстрее (но на той же самой связке указанный документ проводится еще дольше!!!).
Внимание, вопрос - как понять тормозит MSSQL или нет? Существуют ли какие то бенчмарки именно для сервера? Почему он так долго выполняет этот запрос (косой, кривой, неправильно написанный, 18 вложенных циклов и т.п.), при том, что другие инструменты страшной нагрузки не показывают? Как говорится - чего стоим, кого ждем?

План запроса покури, на что именно идут 15 секунд.. и оптимизируй наздоровье

http://its.1c.ru/db/metod8dev#browse:13:-1:1989:2035:2510:2514

типовой запрос по партиям начинает работать в 5 раз быстрее простым выносом виртуальных таблиц во временные. а вообще его можно раз в 15 заставить быстрее работать.

(1) С запросом все понятно. Но вдруг это сервер тормозит, надо же разобраться

(3) типовой запрос в какой конфе?

(2) Это я видел, но я не пойму, что с сервером не так. Разве очередь к диску 10 (в чем они ее измеряют?) это много? Я читал, что тормозить начинает после 20-30.

(3) Да, это обязательно сделаем! Вообще 1С загадка - сами пишут в книгах не делать соединения с вложенными запросами и виртуальными таблицами и сами же делают в типовых конфах!

план запроса смотрел?

(7) А если бы на постгре такое было, то вообще бы не дождался ответа )))

(5) в УТ 10.3

(8) видел. 18 вложенных циклов, пипец, считать устал. Но вопрос у меня все таки как понять тормозит MSSQL или нет?

(5) угадай с одного раза, про какой запрос я горворю

(7) многие вещи в типовых тянутся с 8.0, когда временных таблиц еще не было

(9) На постгре я бы сам наверное быстрее разобрался. Кстати интересная мысль - поставить на тот же самый сервер постгре и сравнить производительность той же базы на нем!

(11) тормозят 1.5 млн чтений

(15) Постгре воообще не любит соединения с подзапросами, прям кровь из носу

а может РЛС еще действует?

(17) Говорят только внешние соединения не любит, с остальными все как у MSSQL. Но сам не проводил экспериментов.

(16) ну дык получается - поставим SSD, вынесем базу и tempdb на него и все наладится? Иначе каждый запрос надо руками исправлять. Я и хочу это заранее понять, в идеале, не покупая SSD

(20) там таких запросов всего несколько, исправив которые всё станет лучше.

а ставить ssd не надо

http://wiki.mista.ru/doku.php?id=it:analiz_sql_block

переходи на отложенное проведение по партиям

(23) По цупу уже проверяли блокировки же

(20) 2 запроса там. На упр и бух учет.

(18) RLS? она влияет на производительность? но у нас нет такого

(26) это в УПП, в УТ один, наверное

(21) так скорее всего и сделаю, спасибо!

(24) да, тоже реализуем такое, но у нас пользователи крик подняли, что хотят иметь документы сразу. Будем делать и так и так. Отложенное уже написано, а запросы поправить быстро

ну и как всегда вопрос: обновление статистики на SQL настроено?

(23) хм, спасибо. Но там скорее всего не в блокировках дело. Я проверял даже когда ночью никого нет, время проведения от этого почти не зависит. Там тупо много чтения и вложенных циклов, хочется понять, может быть можно как то сервер заставить выполнять запрос побыстрее.

(31) с этого начали. Каждую ночь пересчитываем

>>>Ну в момент обработки документа подрастает очередь диска до 10.

это ЖЕСТЬ !!!

очередь к диску не должна быть более 1

(34) О! Это интересно. Т.е. получается проблема в тормозном диске?

(35) нет

(35) в 1.5 млн чтений

(36) ну в смысле, если предположить, что запросы оптимизировали

(34) кто тебе такое сказал? может, для десктопного диска wd green так и должно быть, а для нормального рэйда или СХД это вполне может быть нормой.
в данном случае так параллелизм скуляки отрабатывает, скорее всего (даже если его в плане нет)

(38) Ключевой момент в том что подскакивает.
Если бы постоянно было, то да мощности диска не хватает

(35)не обязательно именно в нем корень проблемы, но переход на быстрые диски гарантировано очень сильно уменьшат проблему...

сделайте (23) при работающей системе (когда все работают и проводят доки) и выложите результаты сюда, тогда будет понятно

а кстати может парараллельность отключить?

(40) нет, это вообще только в момент этого самого запроса происходит, остальное время меньше 1

(41) проблема. в. запросе.

(0) Тут вот Как быстро найти неоптимальности в запросе (волшебная консоль запросов)
предлагали потестить всякие запросы, может еще можно забесплатно ваш запрос, который тормозит, проанализировать...

(43) вот видишь - значит хватает мощности то

(44) Всегда можно экстенсивным путем уменьшить проблему

(45) что там тестить? оно покажет - вынесите виртуальные таблицы во временные.

(42) макс. параллелизм 1 стоит, специально еще раз проверил. Вообще все по списку тюнинга MSSQL проверял первым делом

(39) замечено экспериментально (на разных серверах, и новых и стрых и ссд и 15тыс ), при очереди 5 наступает дикий тупняк 1с

(50) у меня не наступает

(45) да с запросом все понятно, там куча соединений с вложенными запросами, так делать не хорошо

(50)+ да и вообще тебе пишут - проверяли ночью с неработающими пользователями - разницы нет.

(46) так меня это и удивляет. Причем на этом же MSSQL лежит еще бухгалтерская база (сервер 1с стоит на другом серваке), бухи не жалуются вообще никогда на производительность.

(48) да, это вопрос решенный, сейчас займусь

(44) скорее всего причина действительно в запросе (плюс рельсе), но ее вполне можно прибить и железом.... тут как говорится "есть нюансы"...

а возможно например причина в наличии одного документа в будущей дате, и тогда режим проведения всегда "неоперативный", а ведь при оперативном режиме проведение ЛЕТАЕТ !!!

(56) в 20 раз ты диски не увеличишь

Ладно, всем спасибо! Я вроде понял, что делать дальше, похоже сервер тут не причем, это радует. Но SSD уже заказал, пусть будут )

(58) отправь мне один

(58) у нас купили сервак с ссд, хороший и дорогой....

поставили базы - через месяц пошли отказы дисков, сейчас поменяли на обычные....

диски - на экспертизу, она выясняла - диски нормальные но вот райд контроллер чудит не по детски...

так, что диски - они такие :)))

я на этом потратил не один день подлечивая базы после всего этого....

(0) если не разберетесь, можем бесплатно сделать аудит http://www.gilev.ru/audit/

(60) ну вроде не самые дешевые заказал, intel s3700. Продавец клянется, что пока еще обратно не приносили.
Можно на них сначала tempdb только положить, посмотреть что будет

(60) (62) Вроде не советуют ССД в райд ставить...

(63) а в чем могут быть проблемы? зеркало просто - читать быстрее будет

(63) практически на всех хостингах ссд в райдах...

вообще для ссд замечателен 50 райд из 8 дисков, просто улет как работает...

(62) контроллер может быть не совместимым :)

(65) Ну посмотрим. Всегда есть вариант программного райда. Вообще, есть мнение, что аппаратные райды это атавизм времен слабых процессоров. Что на современных серверах они ничего не дают.

(64) хз почему, но Андрей Бурмистров из команды gilev.ru говорит что наблюдают такую закономерность - падает скорость

(56) а можно уточнить - документ в будущем должен быть проведен или достаточно его наличия, чтобы включился неоперативный режим?

Кому интересно, докладываю результат:
1. Установкой SSD достигнуто ускорение с 15 до 14.5 секунд на этом запросе. Единственное объяснение, которое удалось придумать - райд из 4-х САС дисков достаточно быстр сам по себе.
2. Переносом вложенного запроса во временную таблицу достигнуто ускорение с 15 до 1 секунды. (делалось до установки SSD)
3. Отложенное проведение написано и внедрено, все щасливы.

Собственно всем еще раз огромное спасибо за советы!

(69) т.е. информация в (3) была абсолютно верной (в т.ч. про "в 15 раз")

(70) Абсолютно точно

(71) а что насчет (59)?

(72) Как в анекдоте, хотел отправить 100$ но уже заклеил конверт ;-)

(0) > Есть большая база УТ и в ней есть документ, который долго проводится (45 секунд). Долго разбираемся почему.
Выяснено, что виноват типовой запрос по партиям. Выполняется 15 секунд. Видимо есть еще какие то тормозные. Если отключить партионный учет, то весь документ проводится за 8 секунд.

Да вы охренели ТАК РАБОТАТЬ. Если бы у меня так документы проводились бы я бы застрелился наверное.

(74) Мы были близки к этому, но решили напоследок попробовать что то изменить

(74) Документ документу рознь, не понятно какие проверки сделаны и по скольким регистрам, а также кол-во строк ТЧ.

(76) + можно воспользоваться http://catalog.mista.ru/public/173394/

(74) а я б не успел....

(6) не более 2*кол-во дисков

(79) -> (39)

Анализ ключевых показателей производительности
https://msdn.microsoft.com/ru-ru/mt631603.aspx

вот например: https://technet.microsoft.com/ru-ru/library/dn894707(v=ws.11).aspx#BKMK_SequentialIOTests на картинке максимальная производительность на глубине очереди 4*количество дисков

а кратковременная очередь вообще ни о чем не говорит