Поэтому я хочу запустить статистику обновлений для всех таблиц в моей базе данных. Одно ограничение заключается в том, что я не могу запускать статистику обновления более чем для 20 статистических таблиц одновременно. Например, если таблица A имеет 40 статистических данных, я должен разбить это на 2 утверждения статистики обновления. Это связано с тем, что некоторые из этих таблиц действительно большие, а приложение, над которым я работаю, имеет тайм-аут при вызовах базы данных.
Я пытался распараллелить этот процесс. Сначала я попытался создать задания с максимум 20 таблицами статистики на блок и с помощью parallel.foreach. Однако я заметил, что даже при том, что я установил maxDegreeOfParallelism на 5, часто только 3 запроса выполнялись в моей базе данных за раз. Я читал о том, как parallel.foreach делает некоторые вещи с совместным использованием ресурсов / разделением между потоками, но я не чувствую, что есть причина использовать это, если я просто делаю один вызов базы данных для каждой задачи.
Затем я попытался создать задачи и ограничить количество активных задач с помощью семафоров. Используя то же ограничение в 5 задач, я смог увидеть 5 запросов, выполняемых одновременно в базе данных, но в целом не заметил большого выигрыша в производительности по сравнению с использованием parallel.foreach.
Теперь меня действительно интересует, насколько скорость этого процесса зависит от количества запущенных Update Statistics. Некоторые вещи я заметил, но могу ошибаться. Всякий раз, когда я пытаюсь запустить два Update statistics одновременно на одном столе
--assume these are running in different tasks
Update Statistics A (stattable1, stattable2,....stattable20);
Update Statistics A (stattable21, stattable22....);
один запрос кажется заблокированным, пока не завершится другой. Думаю, это имеет смысл, поскольку мы пытаемся сканировать одну и ту же таблицу.
Затем при одновременном запуске Update Statistics на двух разных таблицах
--assume these are running in different tasks
Update Statistics A (stattable1, stattable2,....);
Update Statistics B (stattable1, stattable2....);
Я заметил, что каждый запрос занимает больше времени, чем если бы я просто запускал одно обновление за раз, однако эта задержка, похоже, не полностью блокирует (т.е. если Update Statistics A занимает 2 минуты, а Update Statistics B занимает 2 минуты, то для них обоих это может для завершения потребуется 3 минуты, а не 4). Это то, в чем я действительно не уверен, насколько эта производительность масштабируется при параллельном выполнении большего количества запросов.
В основном мне просто интересно, имеет ли смысл использовать задачи по сравнению с parallel.foreach, а также лучший способ структурировать эти запросы для повышения производительности.
Почему приложение обновляет всю статистику в вашей базе данных? Есть мышеловки получше. В любом случае, нет никакого способа ускорить обновление статистики, кроме как ускорить ввод-вывод (что, как я подозреваю, является замедлением, которое вы наблюдаете). Они берут то, что берут, вы можете обменять производительность на точность (например, меньшие размеры выборки), но это все.
@FrankerZ - это тайм-аут для всего приложения, также обычно есть только 5-10 таблиц с более чем 20 статистикой, поэтому я не думаю, что это действительно сильно влияет на производительность.
@AaronBertrand - приложение имеет функцию оптимизации, которую многие пользователи планируют запускать каждую ночь. Мой главный вопрос о производительности на самом деле был о том, как именно параллельные запросы работают в sqlserver. Как я заметил, быстрее выполнять 2 запроса одновременно, чем один за другим. Но, конечно, в какой-то момент это замедлится, и я просто не уверен, каким будет ограничивающий фактор. В какой-то момент я замечаю, что запросы, выполнение которых может занять 1 минуту, занимают до 10 минут при параллельном выполнении с другими 5 запросами. В основном интересно узнать, что определяет эту производительность
Так могут ли многие пользователи запланировать оптимизацию одних и тех же таблиц одновременно? Это кажется ... ну ... неоптимальным. Почему бы вам просто не «оптимизировать» все таблицы и не заставлять их делать это принудительно? Вам нужно будет глубже изучить показатели, стоящие за этими запросами, чтобы получить какие-либо значимые ответы. Существует около 86 000 причин, по которым запрос может выполняться медленнее. Мы не можем догадаться.
@AaronBertrand есть проверки для предотвращения подобных случаев. Да, я в основном надеялся, что может быть проверенный и верный способ распараллеливания, который я просто не смог найти в Google. Думаю, мне просто нужно попробовать поиграть и посмотреть, что дает мне лучшую производительность
@AaronBertrand, возможно, вы хотели сказать «просто« оптимизируйте »все таблицы за ночь и не делайте этого пользователям разрешать»? :) Конечно, оставьте кнопку в интерфейсе - просто прикрепите ее к случайному индикатору выполнения ... [злая ухмылка]
@Brian: Я имел в виду, что не заставляйте их думать, что единственный способ сделать запросы быстрее - это нажать кнопку. Им не нужно думать, что их запросы выполняются медленно, потому что вы можете решить «проблему» в различных, не заставляя их нажимать кнопку.
Это справедливо, @AaronBertrand и я, было, делаем предположения о приложении и о том, кто его пользователи.





Почему бы тебе просто не увеличить тайм-аут?