web-dev-qa-db-ja.com

SOS_SCHEDULER_YIELD待機のトラブルシューティング

私たちの企業ERP（Dynamics AX 2012））を実行していると、私たちの運用環境は開発システムよりもはるかに遅いように見えました。

トレースを実行しながら開発環境と本番環境の両方で同じアクティビティを実行した後、本番環境ではSQLクエリの実行が開発と比較して非常に遅いことを確認しました（平均で10〜50倍遅い）。

最初は、これが負荷に起因するものであり、営業時間外に本番環境で同じアクティビティを再実行したところ、トレースで同じ結果が見つかりました。

SQL Serverで待機統計をクリアし、サーバーを通常の運用負荷でしばらく実行させてから、次のクエリを実行しました。

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'CLR_SEMAPHORE',    N'LAZYWRITER_SLEEP',
        N'RESOURCE_QUEUE',   N'SQLTRACE_BUFFER_FLUSH',
        N'SLEEP_TASK',       N'SLEEP_SYSTEMTASK',
        N'WAITFOR',          N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
        N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
        N'XE_TIMER_EVENT',   N'XE_DISPATCHER_JOIN',
        N'LOGMGR_QUEUE',     N'FT_IFTS_SCHEDULER_IDLE_WAIT',
        N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
        N'CLR_AUTO_EVENT',   N'DISPATCHER_QUEUE_SEMAPHORE',
        N'TRACEWRITE',       N'XE_DISPATCHER_WAIT',
        N'BROKER_TO_FLUSH',  N'BROKER_EVENTHANDLER',
        N'FT_IFTSHC_MUTEX',  N'SQLTRACE_INCREMENTAL_FLUSH_SLEEP',
        N'DIRTY_PAGE_POLL',  N'SP_SERVER_DIAGNOSTICS_SLEEP')
    )
SELECT
    [W1].[wait_type] AS [WaitType],
    CAST ([W1].[WaitS] AS DECIMAL(14, 2)) AS [Wait_S],
    CAST ([W1].[ResourceS] AS DECIMAL(14, 2)) AS [Resource_S],
    CAST ([W1].[SignalS] AS DECIMAL(14, 2)) AS [Signal_S],
    [W1].[WaitCount] AS [WaitCount],
    CAST ([W1].[Percentage] AS DECIMAL(4, 2)) AS [Percentage],
    CAST (([W1].[WaitS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgWait_S],
    CAST (([W1].[ResourceS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgRes_S],
    CAST (([W1].[SignalS] / [W1].[WaitCount]) AS DECIMAL (14, 4)) AS [AvgSig_S]
FROM [Waits] AS [W1] INNER JOIN [Waits] AS [W2] ON [W2].[RowNum] <= [W1].[RowNum]
GROUP BY [W1].[RowNum], [W1].[wait_type], [W1].[WaitS],
    [W1].[ResourceS], [W1].[SignalS], [W1].[WaitCount], [W1].[Percentage]
HAVING SUM ([W2].[Percentage]) - [W1].[Percentage] < 95; -- percentage threshold

私の結果は次のとおりです。

WaitType               Wait_S  Resource_S  Signal_S  WaitCount  Percentage  AvgWait_S  AvgRes_S  AvgSig_S
SOS_SCHEDULER_YIELD   4162.52        3.64   4158.88    4450085       77.33     0.0009    0.0000    0.0009
ASYNC_NETWORK_IO       457.98      331.59    126.39     351113        8.51     0.0013    0.0009    0.0004
PAGELATCH_EX           252.94        5.14    247.80     796348        4.70     0.0003    0.0000    0.0003
WRITELOG               166.01       48.01    118.00     302209        3.08     0.0005    0.0002    0.0004
LCK_M_U                145.47      145.45      0.02        123        2.70     1.1827    1.1825    0.0002

したがって、一見して最大の待機はSOS_Scheduler_Yieldであり、私はググったところ、通常はCPUが追いついていないことに関連していることがわかりました。

次に、このクエリを続けて複数回実行しました。

SELECT *
FROM sys.dm_os_schedulers
WHERE scheduler_id < 255

Runnable_tasks_countまたはpending_disk_io_countがゼロ以外のスケジューラを探しているはずですが、ほとんどの場合、基本的にゼロです。

また、Dynamics AXのワークロードは通常OLTPの性質であり、8を変更しても上記の待機統計に大きな違いはなかったため、並列処理の最大次数が1に設定されたことにも言及する必要があります。それらは同じパフォーマンスの問題でほぼ同じになりました。

私はここからどこに行くべきか途方に暮れています、私は基本的にCPUに縛られているように見えますがrunnable_tasksやIOを待っていないSQLサーバーを持っています。

IOこのSQL Serverのサブシステムは、実際のデータベースを含むドライブでSQLIOを実行すると、かなり低い数値になる可能性があるため、特定のタイプでは毎秒10MBと考えられるため、あまり良くありません。ほとんどのデータベースをキャッシュしているサーバー上のメモリの量が原因で、SQLが待機しているようには見えません。

役立つ環境情報は次のとおりです。

本番環境：

  • SQLサーバー
  • HP ProLian DL360p Gen8
  • Intel Xeon E5-2650 0 @ 2.00GHz x 2、ハイパースレッディング（32論理コア）
  • 184GBメモリ
  • Windowsサーバー2012
  • SQL Server 2012 Standardの2つのインスタンス（RTM、パッチ未適用）
  • RAID 1 279GBドライブ（15k）C：ドライブ、データベースとオペレーティングシステムを含む
  • ページファイルとTempDBが別々のドライブにある（ソリッドステート）

私のDEV：

  • Hyper-VがホストするSQL ServerおよびDynamics AX 2012 AOSサーバー
  • ハイパースレッディングを備えたCore i7 3.4ghz（8つの論理コア）
  • 8GBのメモリ
  • Windows Server 2008 R2
  • VM全体のSSD。

私は他に探すべきことについての情報を歓迎します。

sql-serverperformancesql-server-2012wait-types
14
Nicholas Peterson

したがって、これを解決し、CPU周波数を増減するSQLサーバーで電源管理機能が有効になっていることがわかりましたが、小さな需要に対応するには十分な速度ではなく、SOS_Scheduler_Yield待機が導入されました。常に高パフォーマンスで実行するように変更した後、問題はなくなり、待機はより正常になりました（LatchIOタイプのもの）。

16
Nicholas Peterson