SQL Server - изменение MAXDOP: как измерить влияние на производительность?

Я пытаюсь уменьшить ожидания CXPACKET в базах данных SQL Server 2012.SQL Server - изменение MAXDOP: как измерить влияние на производительность?

Я собираюсь настроить MAXDOP и порог затрат для параллелизма, чтобы сделать это. См. Brent Ozar's article.

Чтобы оценить влияние изменений на время ожидания, я отслеживаю время ожидания каждые 15 минут, используя sys.dm_os_wait_stats и следуя this advice. Я хочу сделать 2 недели чтения до того, как я настроюсь и через 2 недели.

Но, я также заинтересован в отслеживании общей производительности запросов. Что было бы хорошим способом увидеть, как запросы выполняются до и после изменений - за те же 2 недели до/2 недели после таймфрейма? Есть ли sprocs, которые дадут мне эти данные?

источник

2013-09-26 MattW

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

От того, что вы сказали, нет причин, по которым я бы опустил MaxDOP на основе этого. Вместо этого я бы пошел с типичным советом до 8 с не более чем количеством ядер в одном узле NUMA для OLTP.

В вашем случае я бы посмотрел ваши самые дорогие запросы, используя Query Stats вместе с вашими самыми большими запросами в соответствии с server-side trace. Если вы можете настроить самых крупных нарушителей, которые вы видите здесь, тогда у вас будет более быстрый сервер вместе с пониженным типом ожидания CXPacket.

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

Пожалуйста, не стесняйтесь ответить здесь, на этот вопрос или на мой блог, на любые другие, которые приходят.

источник

2013-10-11 13:06:33

Спасибо Стив.Мой порог стоимости для параллелизма сейчас только в 5, что кажется низким. В ближайшее время я собираюсь подняться - я нахожусь в середине аппаратной миграции и хочу дождаться, пока БД не будут работать на новом оборудовании, прежде чем выбрать новый порог, но я знаю, что он будет выше 5. Я нахожусь на правильный путь с этим подходом? – MattW

Вид, это уменьшит количество параллелизма, но ваши ожидания будут получены из более крупных запросов. Для этого параметра было бы неплохо запустить ваш сервер примерно на 50 и проверить его, как [Иеремия Пресчка] (http://www.brentozar.com/archive/2013/09/five-sql-server-settings -отмена /), который знает больше, чем я. Это хорошее начало, но у вас будет больше удачи в настройке больших запросов. –

Ожидания CXPACKET не обязательно указывают на проблему с параллелизмом - это обычно является симптомом какой-либо другой проблемы.

Когда запрос идет параллельно, скажем, через 10 потоков, и один из этих 10 потоков занимает больше времени, чем остальные, чтобы завершить свою работу, остальные 9 потоков собираются на ожидание ожиданий CXPACKET.

Какие еще виды высокого ожидания вы видите?

источник

2013-09-26 13:25:11

Вот список топ-10 (в этом отношении): LAZYWRITER_SLEEP, CXPACKET, SLEEP_TASK, DISPATCHER_QUEUE_SEMAPHORE, XE_TIMER_EVENT, XE_DISPATCHER_WAIT, SQLTRACE_INCREMENTAL_FLUSH_SLEEP, OLEDB, PAGEIOLATCH_SH, WriteLog. Я думаю, что параллелизм является проблемой, главным образом потому, что мой порог затрат для параллелизма равен 5, но я могу проверить, что многие из моих основных операторов OLTP кэшируются со стоимостью 60 или выше. Я думаю, мне нужно изменить это с 5 на более чем 60 или 100. – MattW

Запустите этот скрипт [link] (http://pastebin.com/sixjgAVR) - потребуется 5 минут. Откройте пять типов ожиданий, которые он возвращает. –

Я ценю помощь, но я не могу просто стереть нашу статистику ожиданий. Они собираются через 15 минут, и это отбрасывает это. – MattW

Основываясь на вышесказанном, кажется, что вы можете использовать некоторую утилиту, которая поможет вам контролировать производительность запросов.

Я могу предложить ApexSQL Monitor (коммерческий инструмент, но предлагает бесплатную пробную версию), который может хранить историческую информацию, поэтому вы можете просмотреть детали до и после уменьшения MAXDOP - и вы можете просмотреть общую производительность запросов.

Кроме того, вы также можете найти хорошее объяснение возможных причин использования CXPACKET и MAXDOP в этой статье http://www.sqlshack.com/troubleshooting-the-cxpacket-wait-type-in-sql-server/.Вот некоторые ключевой вынос из статьи:

шагов, которые рекомендуются в диагностике причин высокого CXPACKET значений статистики ожидания (прежде чем делать коленный рефлекс и что-то изменить на SQL Server):

Не устанавливайте MAXDOP в 1, так как это никогда не является решением
Изучите историю запросов и CXPACKET, чтобы понять и определить, произошло ли это что-то однократно или дважды, поскольку это может быть просто исключение в системе, которая обычно правильная работа
Проверьте индексы и статистику по таблицам u СЭД по запросу и убедитесь, что они до настоящего времени
Проверка стоимости Порог параллельности (CTFP) и убедитесь, что значение, используемое подходит для вашей системы
Проверьте, находится ли CXPACKET сопровождается LATCH_XX (возможно, с PAGEIOLATCH_XX или SOS_SCHEDULER_YIELD). Если это так, то значение MAXDOP должно быть опущено в соответствии с вашими аппаратными средствами.
Проверьте, является ли CXPACKET сопровождающим LCK_M_XX (обычно с IO_COMPLETION и ASYNC_IO_COMPLETION). Если это так, то параллелизм не является узким местом. Устранение неполадок при тех ждать статистику, чтобы найти причину проблемы и решения

источник

2016-10-07 07:56:34

SQL Server - изменение MAXDOP: как измерить влияние на производительность?

ответ

Смежные вопросы