web-dev-qa-db-ja.com

SQL Server 2014のMAXDOP設定

私はこの質問が何度も尋ねられ、それに対する回答もあることを知っていますが、私はまだこの主題についてもう少しガイダンスが必要です。

以下はSSMSからの私のCPUの詳細です：

CPU

以下は、DBサーバーのタスクマネージャーの[CPU]タブです。

CPU Tab

以下の式に従って、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％です：

Wait Statistics

私は専門家からの推奨に関する複数の記事を参照し、 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秒間以下は、検出結果と待機統計の出力です。

sp_blitzfirst

sql-serversql-server-2014configurationmaxdop
8
Learning_DBAdmin

偽物

その待機統計レポートが悪臭を放つ理由は次のとおりです。サーバーが稼働している時間はわかりません。

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として表示される場合があります。

サードパーティの監視ツールがない場合は、自分で待機統計をキャプチャする価値があります。

13
Erik Darling

待機統計は単なる数値です。サーバーがなんらかの処理を行っている場合は、何らかの待機が発生する可能性があります。また、定義により、最も高い割合を持つ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を変更する前後にスループットを監視する必要があります。

10
Joe Obbish

  1. 「開始」maxdopは4にする必要があります。 numaノードあたりのコアの最小数は最大8。式が正しくありません。

  2. 特定のタイプの待機の割合が高い場合は、何も意味しません。 SQLのすべてが待機するため、何かが常に最高です。高いcxpacketが待機する唯一のことは、並列処理の割合が高いことを意味します。 CPUは全体的に（少なくとも提供されたスナップショットでは）高く見えないため、おそらく問題はありません。

  3. 問題を解決する前に、問題を明確にしてください。どのような問題を解決しようとしていますか？この場合、問題をcxpacket待機の高い割合として定義したようですが、それ自体は問題ではありません。

0
Jared Karney