Самый быстрый способ обновить всю статистику в базе данных?

Поэтому я хочу запустить статистику обновлений для всех таблиц в моей базе данных. Одно ограничение заключается в том, что я не могу запускать статистику обновления более чем для 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, а также лучший способ структурировать эти запросы для повышения производительности.

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

ugh StackExchange 22.10.2018 18:04

Почему приложение обновляет всю статистику в вашей базе данных? Есть мышеловки получше. В любом случае, нет никакого способа ускорить обновление статистики, кроме как ускорить ввод-вывод (что, как я подозреваю, является замедлением, которое вы наблюдаете). Они берут то, что берут, вы можете обменять производительность на точность (например, меньшие размеры выборки), но это все.

Aaron Bertrand 22.10.2018 18:04

@FrankerZ - это тайм-аут для всего приложения, также обычно есть только 5-10 таблиц с более чем 20 статистикой, поэтому я не думаю, что это действительно сильно влияет на производительность.

Steven Hsu 22.10.2018 18:06

@AaronBertrand - приложение имеет функцию оптимизации, которую многие пользователи планируют запускать каждую ночь. Мой главный вопрос о производительности на самом деле был о том, как именно параллельные запросы работают в sqlserver. Как я заметил, быстрее выполнять 2 запроса одновременно, чем один за другим. Но, конечно, в какой-то момент это замедлится, и я просто не уверен, каким будет ограничивающий фактор. В какой-то момент я замечаю, что запросы, выполнение которых может занять 1 минуту, занимают до 10 минут при параллельном выполнении с другими 5 запросами. В основном интересно узнать, что определяет эту производительность

Steven Hsu 22.10.2018 18:10

Так могут ли многие пользователи запланировать оптимизацию одних и тех же таблиц одновременно? Это кажется ... ну ... неоптимальным. Почему бы вам просто не «оптимизировать» все таблицы и не заставлять их делать это принудительно? Вам нужно будет глубже изучить показатели, стоящие за этими запросами, чтобы получить какие-либо значимые ответы. Существует около 86 000 причин, по которым запрос может выполняться медленнее. Мы не можем догадаться.

Aaron Bertrand 22.10.2018 18:13

@AaronBertrand есть проверки для предотвращения подобных случаев. Да, я в основном надеялся, что может быть проверенный и верный способ распараллеливания, который я просто не смог найти в Google. Думаю, мне просто нужно попробовать поиграть и посмотреть, что дает мне лучшую производительность

Steven Hsu 22.10.2018 18:28

@AaronBertrand, возможно, вы хотели сказать «просто« оптимизируйте »все таблицы за ночь и не делайте этого пользователям разрешать»? :) Конечно, оставьте кнопку в интерфейсе - просто прикрепите ее к случайному индикатору выполнения ... [злая ухмылка]

Brian 22.10.2018 18:41

@Brian: Я имел в виду, что не заставляйте их думать, что единственный способ сделать запросы быстрее - это нажать кнопку. Им не нужно думать, что их запросы выполняются медленно, потому что вы можете решить «проблему» в различных, не заставляя их нажимать кнопку.

Aaron Bertrand 22.10.2018 19:02

Это справедливо, @AaronBertrand и я, было, делаем предположения о приложении и о том, кто его пользователи.

Brian 22.10.2018 20:15
Стоит ли изучать PHP в 2026-2027 годах?
Стоит ли изучать PHP в 2026-2027 годах?
Привет всем, сегодня я хочу высказать свои соображения по поводу вопроса, который я уже много раз получал в своем сообществе: "Стоит ли изучать PHP в...
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
Поведение ключевого слова "this" в стрелочной функции в сравнении с нормальной функцией
В JavaScript одним из самых запутанных понятий является поведение ключевого слова "this" в стрелочной и обычной функциях.
Приемы CSS-макетирования - floats и Flexbox
Приемы CSS-макетирования - floats и Flexbox
Здравствуйте, друзья-студенты! Готовы совершенствовать свои навыки веб-дизайна? Сегодня в нашем путешествии мы рассмотрим приемы CSS-верстки - в...
Тестирование функциональных ngrx-эффектов в Angular 16 с помощью Jest
В системе управления состояниями ngrx, совместимой с Angular 16, появились функциональные эффекты. Это здорово и делает код определенно легче для...
Концепция локализации и ее применение в приложениях React ⚡️
Концепция локализации и ее применение в приложениях React ⚡️
Локализация - это процесс адаптации приложения к различным языкам и культурным требованиям. Это позволяет пользователям получить опыт, соответствующий...
Пользовательский скаляр GraphQL
Пользовательский скаляр GraphQL
Листовые узлы системы типов GraphQL называются скалярами. Достигнув скалярного типа, невозможно спуститься дальше по иерархии типов. Скалярный тип...
0
9
190
0

Другие вопросы по теме