SQL Server 2014のMAXDOP設定


8

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

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

CPU

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

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マイクロソフトによる提案も検討しました。ただし、これに最適な値は何なのか本当にわかりません。

ここで同じトピックに関する質問を1つ見つけましたが、Kinの提案に沿って行くとMAXDOP4になります。同じ質問で、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)でMAXDOP0の場合、の待機時間は70%近くでしたCXPACKET

sp_blitzfirstはエキスパートモードで60秒間実行しました。以下は、検出結果と待機統計の出力です。

sp_blitzfirst


私は彼の回答における@JaredKarneyのコメントに同意します。何を修正/解決しようとしていますか?パフォーマンスが悪いですか?高いCXPACKET待機が悪いと思うのはなぜですか?あなたの状況がこの問題に関する他のすべての質問と回答と異なる理由を詳しく説明していただけませんか?
John aka hot2use

@ hot2useはい、パフォーマンスに問題があり、パフォーマンスを低下させる可能性のあるすべての可能性を確認しようとしています。私は、CXPACKET待機統計の専門家ではないため、専門家からのアドバイスを求めていました。
Learning_DBAdmin

回答:


13

偽物

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

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

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


10

待機統計は単なる数値です。サーバーがなんらかの処理を行っている場合は、何らかの待機が発生する可能性があります。また、定義により、最も高い割合を持つ1つの待機が必要です。これは、何らかの正規化がなければ何も意味しません。タスクマネージャーの出力を正しく読んでいる場合、サーバーは55日間稼働しています。つまり、全体で452000 /(55 * 86400)= 0.095待機秒しかありませんCXPACKET。さらに、SQL Server 2014を使用しているため、CXPACKET待機には良性の並列待機と実行可能な待機の両方が含まれます。詳細については、並列処理待機を実行可能にするを参照してください。MAXDOPここで提示した内容に基づいて誤って設定された結論にはジャンプしません。

最初にスループットを測定します。ここに実際に問題がありますか?それはあなたのワークロードに依存するため、私たちはそれを行う方法をあなたに伝えることはできません。OLTPシステムの場合、1秒あたりのトランザクションを測定できます。ETLの場合、1秒あたりにロードされた行を測定する場合があります。

問題があり、システムパフォーマンスを改善する必要がある場合は、その問題が発生したときにCPUを確認します。CPUが高すぎる場合は、クエリを調整するか、サーバーリソースを増やすか、アクティブなクエリの総数を減らす必要があります。CPUが低すぎる場合は、クエリを再度調整するか、アクティブなクエリの総数を増やすか、原因となっている待機タイプがある可能性があります。

待機統計を確認する場合は、パフォーマンスの問題が発生している期間のみ確認する必要があります。過去55日間のグローバルな待機統計を確認するだけでは、ほとんどすべての場合に対処できません。それはあなたの仕事を難しくするデータに不要なノイズを追加します。

適切な調査を完了すると、変更MAXDOPが役立つ場合があります。あなたのサイズのサーバーでは、1、2、4 MAXDOP、または8に固執します。どれがワークロードに最適かはわかりません。MAXDOP結論を出すには、変更の前後にスループットを監視する必要があります。


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

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

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


仮想NUMAはnumaノードごとに2つのコアを簡単に持つことができます。4がnumaノードあたりのコアの最小数であると主張するのはなぜですか?どういう意味ですか?
Max Vernon

-2

最も適切な質問は...パフォーマンスの問題が実際に発生していますか?答えが「いいえ」の場合、問題がないのになぜ問題を探しているのですか?

他の回答が言ったように、すべてが待機し、すべてのCX待機は、クエリが並列化されているかどうかを示します。ここで言及するのは、クエリに問題がある場合、並列処理のコストしきい値が何に設定されているかを確認する必要があることです。並列処理、つまり、並列処理で多くの作業を実行していない小さなクエリは、実行が悪くなる可能性がありますが、実行されているすべての小さいクエリが原因で、並列処理が必要な大きなクエリが遅延しています不完全に。

そうでない場合は、作成を停止する問題はありません。


質問を完全に読んでください。並列処理のコストしきい値が提供されています。
Learning_DBAdmin
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.