私はこの質問が何度も尋ねられ、それに対する回答もあることを知っていますが、私はまだこの主題についてもう少しガイダンスが必要です。
以下はSSMSからの私のCPUの詳細です:
以下は、DBサーバーのタスクマネージャーの[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%です:
私は専門家からの推奨に関する複数の記事を参照し、 Microsoft によるMAXDOP
の提案も調べました。ただし、これに最適な値が何であるかはよくわかりません。
同じトピックに関する質問が1つ見つかりました here ただし、Kinの提案に沿った場合、MAXDOP
は4になるはずです。同じ質問で、Max Vernonに行った場合、 3である必要があります。
貴重なご提案をお願いいたします。
バージョン:Microsoft SQL Server 2014(SP3)(KB4022619)-12.0.6024.0(X64)2018年9月7日01:37:51 Enterprise Edition:Windows NT 6.3のコアベースのライセンス(64ビット)(ビルド9600:)(ハイパーバイザー)
並列処理のコストしきい値は70に設定されています。CTfPは、デフォルトからそれぞれ25と50の範囲の値に対して同じをテストした後、70に設定されています。 default(5)でMAXDOP
が0の場合、CXPACKET
の待機時間は70%近くでした。
sp_blitzfirst
エキスパートモードで60秒間以下は、検出結果と待機統計の出力です。
その待機統計レポートが悪臭を放つ理由は次のとおりです。サーバーが稼働している時間はわかりません。
CPU時間:55日のスクリーンショットで確認できます。
さて、それでは、いくつかの計算をしましょう。
1日は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として表示される場合があります。
サードパーティの監視ツールがない場合は、自分で待機統計をキャプチャする価値があります。
待機統計は単なる数値です。サーバーがなんらかの処理を行っている場合は、何らかの待機が発生する可能性があります。また、定義により、最も高い割合を持つ1つの待機が必要です。これは、何らかの正規化がなければ何も意味しません。タスクマネージャーの出力を正しく読んでいる場合、サーバーは55日間稼働しています。つまり、全体で452000 /(55 * 86400)= 0.095待機秒のCXPACKET
しかありません。さらに、SQL Server 2014を使用しているため、CXPACKET
の待機には、良性の並列待機と実行可能な待機の両方が含まれます。詳細は 並列処理の待機を実行可能にする を参照してください。ここで提示した内容に基づいてMAXDOP
が誤って設定されているという結論にはジャンプしません。
最初にスループットを測定します。ここに実際に問題がありますか?それはあなたのワークロードに依存するため、私たちはそれを行う方法をあなたに伝えることはできません。 OLTPシステムの場合、1秒あたりのトランザクションを測定できます。ETLの場合、1秒あたりにロードされた行などを測定できます。
問題があり、システムパフォーマンスを改善する必要がある場合は、その問題が発生したときにCPUを確認します。 CPUが高すぎる場合は、クエリを調整するか、サーバーリソースを増やすか、アクティブなクエリの総数を減らす必要があります。 CPUが低すぎる場合は、クエリを再度調整するか、アクティブなクエリの総数を増やすか、原因となっている待機タイプがある可能性があります。
待機統計を確認する場合は、パフォーマンスの問題が発生している期間のみ確認する必要があります。過去55日間のグローバルな待機統計を確認するだけでは、ほとんどすべての場合に対処できません。それはあなたの仕事を難しくするデータに不要なノイズを追加します。
適切な調査が完了したら、MAXDOP
を変更すると解決する可能性があります。あなたのサイズのサーバーの場合、MAXDOP
1、2、4、または8に固執します。どれがワークロードに最適かはわかりません。結論を出すには、MAXDOP
を変更する前後にスループットを監視する必要があります。
「開始」maxdopは4にする必要があります。 numaノードあたりのコアの最小数は最大8。式が正しくありません。
特定のタイプの待機の割合が高い場合は、何も意味しません。 SQLのすべてが待機するため、何かが常に最高です。高いcxpacketが待機する唯一のことは、並列処理の割合が高いことを意味します。 CPUは全体的に(少なくとも提供されたスナップショットでは)高く見えないため、おそらく問題はありません。
問題を解決する前に、問題を明確にしてください。どのような問題を解決しようとしていますか?この場合、問題をcxpacket待機の高い割合として定義したようですが、それ自体は問題ではありません。