Я знаю, что этот вопрос задавался много раз и также имеет ответы на него, но мне все еще нужно больше рекомендаций по этому вопросу.
Ниже приведены детали моего процессора из SSMS:
Ниже находится вкладка ЦП из диспетчера задач Сервера БД:
Я сохранил настройку 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 секунд в экспертном режиме, и ниже приведен вывод результатов и статистики ожидания:
источник
Ответы:
фиктивный
Вот почему этот отчет о статистике ожидания воняет: он не говорит вам, как долго работал сервер.
Я вижу это на скриншоте времени процессора: 55 дней!
Хорошо, так что давайте сделаем немного математики.
математический
Есть 86 400 секунд в день.
Ответ есть?
4,752,000У вас есть всего
452,488несколько секунд CXPACKET.Что дает вам ... 10 (это ближе к 9,5, если вы делаете настоящую математику, здесь).
Таким образом, хотя CXPACKET может составлять 62% времени ожидания вашего сервера, это происходит только в 10% случаев.
Забудь об этом
Вы внесли правильные изменения в настройки, пришло время выполнить фактическую настройку запросов и индексов, если вы хотите существенно изменить числа.
Другие соображения
CXPACKET может возникнуть из-за перекосов параллелизма:
В более новых версиях он может отображаться как CXCONSUMER:
В отсутствие стороннего инструмента мониторинга, возможно, стоит собирать статистику ожидания самостоятельно:
источник
Статистика ожидания это просто цифры. Если ваш сервер вообще что-то делает, то, скорее всего, появятся какие-то ожидания. Кроме того, по определению должно быть одно ожидание, которое будет иметь самый высокий процент. Это ничего не значит без некоторой нормализации. Ваш сервер работает в течение 55 дней, если я правильно читаю вывод диспетчера задач. Это означает, что у вас всего 452000 / (55 * 86400) = 0,095 секунд ожидания
CXPACKETв секунду в целом. Кроме того, поскольку вы работаете на SQL Server 2014, вашиCXPACKETожидания включают как параллельные, так и ожидаемые действия. См. Создание параллелизма для более подробной информации. Я бы не стал делатьMAXDOPневерный вывод на основании того, что вы здесь изложили.Я бы сначала измерил пропускную способность. Здесь на самом деле проблема? Мы не можем сказать вам, как это сделать, потому что это зависит от вашей рабочей нагрузки. Для системы OLTP вы можете измерять количество транзакций в секунду. Для ETL вы можете измерить количество строк, загружаемых в секунду, и так далее.
Если у вас есть проблема, и производительность системы должна быть улучшена, я бы проверил ЦП во время, когда вы сталкиваетесь с этой проблемой. Если ЦП слишком высок, вам, вероятно, нужно настроить запросы, увеличить ресурсы сервера или уменьшить общее количество активных запросов. Если ЦП слишком низкий, вам может понадобиться снова настроить свои запросы, увеличить общее количество активных запросов, или может быть какой-то ответственный тип ожидания.
Если вы решите посмотреть статистику ожидания, вы должны просматривать ее только в течение периода, когда у вас возникают проблемы с производительностью. Просмотр глобальной статистики ожиданий за последние 55 дней просто не подходит практически во всех случаях. Это добавляет ненужный шум к данным, что делает вашу работу тяжелее.
После того, как вы закончили надлежащее расследование, возможно, что изменение
MAXDOPпоможет вам. Для сервера вашего размера я бы выбралMAXDOP1, 2, 4 или 8. Мы не можем сказать вам, какой из них будет лучшим для вашей рабочей нагрузки. Вы должны контролировать свою пропускную способность до и после изменения,MAXDOPчтобы сделать вывод.источник
Ваш «стартовый» maxdop должен быть 4; наименьшее количество ядер на узел numa до 8. Ваша формула неверна.
Высокий процент ожидания определенного типа ничего не значит. Все в SQL ждет, поэтому что-то всегда самое высокое. Единственная вещь, которую ожидает высокий cxpacket, это то, что у вас высокий процент параллелизма. Процессор не выглядит высоким в целом (по крайней мере, для предоставленного снимка), поэтому, вероятно, не проблема.
Прежде чем пытаться решить проблему, определите проблему. Какую проблему ты пытаешься решить? В этом случае кажется, что вы определили проблему как высокий процент ожидания cxpacket, но это само по себе не является проблемой.
источник
Я думаю, что самый важный вопрос ... у вас есть проблемы с производительностью? Если ответ «нет», то почему вы ищете проблему, когда ее нет?
Как и в других ответах, все ждет, и все ожидания CX указывают на то, что если у вас параллельные запросы, то я упомяну, возможно, вам стоит посмотреть, какой порог стоимости для параллелизма установлен, если у вас есть проблемы с запросами параллельные, то есть небольшие запросы, которые не выполняют большую часть параллельной работы и, возможно, заставляют их работать хуже, а не лучше, а большие запросы, которые должны идти параллельно, задерживаются из-за всех меньших, которые выполняются плохо.
Если нет, то у вас нет проблем прекратите пытаться создать его.
источник