Настройки MAXDOP для SQL Server 2014


8

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

Ниже приведены детали моего процессора из SSMS:

ЦПУ

Ниже находится вкладка ЦП из диспетчера задач Сервера БД:

Вкладка CPU

Я сохранил настройку MAXDOPна 2, следуя приведенной ниже формуле:

declare @hyperthreadingRatio bit
declare @logicalCPUs int
declare @HTEnabled int
declare @physicalCPU int
declare @SOCKET int
declare @logicalCPUPerNuma int
declare @NoOfNUMA int
declare @MaxDOP int

select @logicalCPUs = cpu_count -- [Logical CPU Count]
    ,@hyperthreadingRatio = hyperthread_ratio --  [Hyperthread Ratio]
    ,@physicalCPU = cpu_count / hyperthread_ratio -- [Physical CPU Count]
    ,@HTEnabled = case 
        when cpu_count > hyperthread_ratio
            then 1
        else 0
        end -- HTEnabled
from sys.dm_os_sys_info
option (recompile);

select @logicalCPUPerNuma = COUNT(parent_node_id) -- [NumberOfLogicalProcessorsPerNuma]
from sys.dm_os_schedulers
where [status] = 'VISIBLE ONLINE'
    and parent_node_id < 64
group by parent_node_id
option (recompile);

select @NoOfNUMA = count(distinct parent_node_id)
from sys.dm_os_schedulers -- find NO OF NUMA Nodes 
where [status] = 'VISIBLE ONLINE'
    and parent_node_id < 64

IF @NoofNUMA > 1 AND @HTEnabled = 0
    SET @MaxDOP= @logicalCPUPerNuma 
ELSE IF  @NoofNUMA > 1 AND @HTEnabled = 1
    SET @MaxDOP=round( @NoofNUMA  / @physicalCPU *1.0,0)
ELSE IF @HTEnabled = 0
    SET @MaxDOP=@logicalCPUs
ELSE IF @HTEnabled = 1
    SET @MaxDOP=@physicalCPU

IF @MaxDOP > 10
    SET @MaxDOP=10
IF @MaxDOP = 0
    SET @MaxDOP=1

PRINT 'logicalCPUs : '         + CONVERT(VARCHAR, @logicalCPUs)
PRINT 'hyperthreadingRatio : ' + CONVERT(VARCHAR, @hyperthreadingRatio) 
PRINT 'physicalCPU : '         + CONVERT(VARCHAR, @physicalCPU) 
PRINT 'HTEnabled : '           + CONVERT(VARCHAR, @HTEnabled)
PRINT 'logicalCPUPerNuma : '   + CONVERT(VARCHAR, @logicalCPUPerNuma) 
PRINT 'NoOfNUMA : '            + CONVERT(VARCHAR, @NoOfNUMA)
PRINT '---------------------------'
Print 'MAXDOP setting should be : ' + CONVERT(VARCHAR, @MaxDOP)

Я все еще вижу высокие времена ожидания, связанные с CXPACKET. Я использую запрос ниже, чтобы получить это:

WITH [Waits] AS
(SELECT
[wait_type],
[wait_time_ms] / 1000.0 AS [WaitS],
([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
[signal_wait_time_ms] / 1000.0 AS [SignalS],
[waiting_tasks_count] AS [WaitCount],
100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
FROM sys.dm_os_wait_stats
WHERE [wait_type] NOT IN (
N'BROKER_EVENTHANDLER', N'BROKER_RECEIVE_WAITFOR',
N'BROKER_TASK_STOP', N'BROKER_TO_FLUSH',
N'BROKER_TRANSMITTER', N'CHECKPOINT_QUEUE',
N'CHKPT', N'CLR_AUTO_EVENT',
N'CLR_MANUAL_EVENT', N'CLR_SEMAPHORE',
N'DBMIRROR_DBM_EVENT', N'DBMIRROR_EVENTS_QUEUE',
N'DBMIRROR_WORKER_QUEUE', N'DBMIRRORING_CMD',
N'DIRTY_PAGE_POLL', N'DISPATCHER_QUEUE_SEMAPHORE',
N'EXECSYNC', N'FSAGENT',
N'FT_IFTS_SCHEDULER_IDLE_WAIT', N'FT_IFTSHC_MUTEX',
N'HADR_CLUSAPI_CALL', N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
N'HADR_LOGCAPTURE_WAIT', N'HADR_NOTIFICATION_DEQUEUE',
N'HADR_TIMER_TASK', N'HADR_WORK_QUEUE',
N'KSOURCE_WAKEUP', N'LAZYWRITER_SLEEP',
N'LOGMGR_QUEUE', N'ONDEMAND_TASK_QUEUE',
N'PWAIT_ALL_COMPONENTS_INITIALIZED',
N'QDS_PERSIST_TASK_MAIN_LOOP_SLEEP',
N'QDS_CLEANUP_STALE_QUERIES_TASK_MAIN_LOOP_SLEEP',
N'REQUEST_FOR_DEADLOCK_SEARCH', N'RESOURCE_QUEUE',
N'SERVER_IDLE_CHECK', N'SLEEP_BPOOL_FLUSH',
N'SLEEP_DBSTARTUP', N'SLEEP_DCOMSTARTUP',
N'SLEEP_MASTERDBREADY', N'SLEEP_MASTERMDREADY',
N'SLEEP_MASTERUPGRADED', N'SLEEP_MSDBSTARTUP',
N'SLEEP_SYSTEMTASK', N'SLEEP_TASK',
N'SLEEP_TEMPDBSTARTUP', N'SNI_HTTP_ACCEPT',
N'SP_SERVER_DIAGNOSTICS_SLEEP', N'SQLTRACE_BUFFER_FLUSH',
N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
N'SQLTRACE_WAIT_ENTRIES', N'WAIT_FOR_RESULTS',
N'WAITFOR', N'WAITFOR_TASKSHUTDOWN',
N'WAIT_XTP_HOST_WAIT', N'WAIT_XTP_OFFLINE_CKPT_NEW_LOG',
N'WAIT_XTP_CKPT_CLOSE', N'XE_DISPATCHER_JOIN',
N'XE_DISPATCHER_WAIT', N'XE_TIMER_EVENT')
AND [waiting_tasks_count] > 0
)
SELECT
MAX ([W1].[wait_type]) AS [WaitType],
CAST (MAX ([W1].[WaitS]) AS DECIMAL (16,2)) AS [Wait_S],
CAST (MAX ([W1].[ResourceS]) AS DECIMAL (16,2)) AS [Resource_S],
CAST (MAX ([W1].[SignalS]) AS DECIMAL (16,2)) AS [Signal_S],
MAX ([W1].[WaitCount]) AS [WaitCount],
CAST (MAX ([W1].[Percentage]) AS DECIMAL (5,2)) AS [Percentage],
CAST ((MAX ([W1].[WaitS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgWait_S],
CAST ((MAX ([W1].[ResourceS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgRes_S],
CAST ((MAX ([W1].[SignalS]) / MAX ([W1].[WaitCount])) AS DECIMAL (16,4)) AS [AvgSig_S]
FROM [Waits] AS [W1]
INNER JOIN [Waits] AS [W2]
ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum]
HAVING SUM ([W2].[Percentage]) - MAX ([W1].[Percentage]) < 95; -- percentage threshold
GO

В настоящее время CXPACKETожидание составляет 63% для моего сервера:

Статистика ожидания

Я ссылался на несколько статей по рекомендации экспертов, а также смотрел на MAXDOPпредложения Microsoft ; Однако я не совсем уверен, что должно быть оптимальным значением для этого.

Я нашел один вопрос на ту же тему здесь, однако, если я пойду с этим предложением Кина, тогда MAXDOPдолжно быть 4. В том же вопросе, если мы пойдем с Максом Верноном, это должно быть 3.

Просьба предоставить ваше ценное предложение.

Версия: Microsoft SQL Server 2014 (SP3) (KB4022619) - 12.0.6024.0 (X64) 7 сентября 2018 г. 01:37:51 Enterprise Edition: Лицензирование на основе ядра (64-разрядная версия) в Windows NT 6.3 (сборка 9600:) (гипервизор) )

Порог стоимости для параллелизма установлен на 70. CTfP был установлен на 70 после тестирования того же самого для значений в диапазоне от по умолчанию до 25 и 50 соответственно. Когда это было по умолчанию (5) и MAXDOPбыло 0, время ожидания было близко к 70% CXPACKET.

Я выполнил sp_blitzfirst60 секунд в экспертном режиме, и ниже приведен вывод результатов и статистики ожидания:

sp_blitzfirst


Я согласен с комментарием @JaredKarney в его ответе: Что вы пытаетесь исправить / решить? Вы сталкиваетесь с плохой работой? Почему вы считаете, что ожидание высокого CXPACKET - это плохо? Не могли бы вы пояснить, почему ваша ситуация отличается от всех других вопросов и ответов по этому вопросу?
Джон aka hot2use

@ hot2use Да, у меня проблема с производительностью и я пытаюсь увидеть все возможные аспекты, которые могут ухудшить производительность. Я не эксперт по статистике ожидания CXPACKET и поэтому хотел бы получить некоторые рекомендации от экспертов.
Learning_DBAdmin

Ответы:


13

фиктивный

Вот почему этот отчет о статистике ожидания воняет: он не говорит вам, как долго работал сервер.

Я вижу это на скриншоте времени процессора: 55 дней!

Хорошо, так что давайте сделаем немного математики.

математический

Есть 86 400 секунд в день.

SELECT (86400 * 55) seconds_in_55_days

Ответ есть? 4,752,000

У вас есть всего 452,488несколько секунд CXPACKET.

SELECT 4752000 / 452488 AS oh_yeah_that_axis

Что дает вам ... 10 (это ближе к 9,5, если вы делаете настоящую математику, здесь).

Таким образом, хотя CXPACKET может составлять 62% времени ожидания вашего сервера, это происходит только в 10% случаев.

Забудь об этом

Вы внесли правильные изменения в настройки, пришло время выполнить фактическую настройку запросов и индексов, если вы хотите существенно изменить числа.

Другие соображения

CXPACKET может возникнуть из-за перекосов параллелизма:

В более новых версиях он может отображаться как CXCONSUMER:

В отсутствие стороннего инструмента мониторинга, возможно, стоит собирать статистику ожидания самостоятельно:


10

Статистика ожидания это просто цифры. Если ваш сервер вообще что-то делает, то, скорее всего, появятся какие-то ожидания. Кроме того, по определению должно быть одно ожидание, которое будет иметь самый высокий процент. Это ничего не значит без некоторой нормализации. Ваш сервер работает в течение 55 дней, если я правильно читаю вывод диспетчера задач. Это означает, что у вас всего 452000 / (55 * 86400) = 0,095 секунд ожидания CXPACKETв секунду в целом. Кроме того, поскольку вы работаете на SQL Server 2014, ваши CXPACKETожидания включают как параллельные, так и ожидаемые действия. См. Создание параллелизма для более подробной информации. Я бы не стал делать MAXDOPневерный вывод на основании того, что вы здесь изложили.

Я бы сначала измерил пропускную способность. Здесь на самом деле проблема? Мы не можем сказать вам, как это сделать, потому что это зависит от вашей рабочей нагрузки. Для системы OLTP вы можете измерять количество транзакций в секунду. Для ETL вы можете измерить количество строк, загружаемых в секунду, и так далее.

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

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

После того, как вы закончили надлежащее расследование, возможно, что изменение MAXDOPпоможет вам. Для сервера вашего размера я бы выбрал MAXDOP1, 2, 4 или 8. Мы не можем сказать вам, какой из них будет лучшим для вашей рабочей нагрузки. Вы должны контролировать свою пропускную способность до и после изменения, MAXDOPчтобы сделать вывод.


0
  1. Ваш «стартовый» maxdop должен быть 4; наименьшее количество ядер на узел numa до 8. Ваша формула неверна.

  2. Высокий процент ожидания определенного типа ничего не значит. Все в SQL ждет, поэтому что-то всегда самое высокое. Единственная вещь, которую ожидает высокий cxpacket, это то, что у вас высокий процент параллелизма. Процессор не выглядит высоким в целом (по крайней мере, для предоставленного снимка), поэтому, вероятно, не проблема.

  3. Прежде чем пытаться решить проблему, определите проблему. Какую проблему ты пытаешься решить? В этом случае кажется, что вы определили проблему как высокий процент ожидания cxpacket, но это само по себе не является проблемой.


Виртуальная NUMA может легко иметь 2 ядра на узел numa. Почему вы утверждаете, что 4 - наименьшее количество ядер на узел numa? Можете ли вы объяснить, что вы имеете в виду?
Макс Вернон,

-2

Я думаю, что самый важный вопрос ... у вас есть проблемы с производительностью? Если ответ «нет», то почему вы ищете проблему, когда ее нет?

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

Если нет, то у вас нет проблем прекратите пытаться создать его.


Пожалуйста, прочитайте вопрос полностью, порог стоимости для параллелизма обеспечен.
Learning_DBAdmin
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.