Высокие CXPACKET ожидают тип в SQL Server даже с MAXDOP = 1
Извините у меня нет ответа для Вас, но я испытываю те же проблемы о системе окон 2003 года.
Достаточно странно мой Windows 2008 VM может получить доступ к файлам хоста после переключения на туземный.
Вы очищали статистику ожидания после понижения максимальной степени параллелизма к 1?
Но нет действительно никакого допустимого простого, универсального эмпирического правила о том, как эта установка должна быть настроена, кроме измерить влияние любых изменений, которые Вы вносите. В дополнение к вышеупомянутым URL я рекомендовал бы читать это сообщение Paul Randal.
Я также предложил бы пересмотреть фокусировку больше на других главных типах ожидания - я часто нахожу, что CXPACKET ожидает, отвлекающий маневр и что они происходят из-за сложных запросов, которые параллелизируются в простые обрабатываемые детали, которые завершаются быстро и больше, обрабатываемые детали I/O-bound, которые занимают много времени для окончания. CXPACKET ожидает, обнаруживаются, когда маленькие, быстрые обрабатываемые детали завершаются и ожидают больших обрабатываемых деталей для завершения.
При рассмотрении настройки определенных запросов план выполнения должен показать Вам, что части запроса занимают много времени для окончания, и затем можно настроиться для рассмотрения проблемы. Устаревшая статистика или плохо выбранные индексы часто являются преступником там.
Это на самом деле не означает, что существует проблема.... параллелизм является хорошей вещью, и CXPacket ожидают, тип показывает просто, потому что SQL Server должен синхронизироваться между различными обрабатываемыми деталями.
То, когда Вы переключаетесь на maxdop=1, является временем выполнения той части кода медленнее чем тогда, когда это идет параллель? Это - реальное доказательство пудинга, так сказать.
Существует много противоречащих статей там, но эти два записаны людьми SQL, которые знают то, о чем они говорят! (хорошо, один из них перешел на сторону Oracle!)
http://itknowledgeexchange.techtarget.com/sql-server/cxpacket-isnt-the-cause-it-is-a-symptom/
http://sqlserverpedia.com/blog/sql-server-bloggers/cxpacket-maxdop-and-your-oltp-system/
Установка MAXDOP вслепую на экземпляре, не рассматривая рабочей нагрузки, IMO, большая ошибка. Это не может обязательно закончить тем, что причинило боль, но это - Хорошая Идея (TM) для поддержки изменения из конфигурации по умолчанию с очень хорошим объяснением. Если Вы не можете объяснить это, не делайте этого.
Из того, что я видел на практике до сих пор, высокий процент CXPACKET ожидает, признак больших параллельных сканирований таблицы.
Используйте SQL Profiler для анализа запросов, работающих на экземпляре: существует хороший шанс, они должны быть индексом, настроенным или возможно даже переписанным, чтобы быть более эффективными. CXPACKET ожидает, просто признак (возможной) проблемы.
The CXPACKET wait type most probably is not what is causing your problem, but rather a consequence of it.
This wait type means that the worker is waiting for some other operation to complete before it can go on. You should check the session that's responsible for the CXPACKET and see what exactly it's waiting for:
SELECT session_id, wait_type, wait_time, start_time, *
FROM SYS.dm_exec_requests
WHERE session_id > 50
GO
SELECT *
FROM sys.dm_os_waiting_tasks AS t
WHERE session_id > 50
GO
Only after you've diagnose the real cause of the problem should you take an action to try and mitigate it.