企業の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であるため、Max Degree of Parallelismが1に設定されていることに言及する必要があります。8パフォーマンスの問題。
私はここからどこへ行くのか迷っています。基本的にはCPUに縛られているようですが、runnable_tasksまたはIOを待っていないSQL Serverがあります。
このSQL ServerのIOサブシステムがあまり良くないことは知っています。実際のデータベースを含むドライブでSQLIOを実行すると数値がかなり低くなる可能性があるためです（特定の種類の読み取り/書き込みでは1秒あたり10MBと考えてください）ほとんどのデータベースをキャッシュしているサーバーのメモリ量のため、SQLがそれを待っているようには見えません。
役立つ環境情報を次に示します。
本番環境：
- SQLサーバー
- HP ProLian DL360p Gen8
- Intel Xeon E5-2650 0 @ 2.00GHz x 2、ハイパースレッディング（32論理コア）
- 184GBメモリ
- Windows Server 2012
- SQL Server 2012 Standardの2つのインスタンス（RTM、パッチ未適用）
- RAID 1 279GBドライブ（15k）C：ドライブ、データベースおよびオペレーティングシステムを含む
- 個別の別個のドライブ上のページファイルとTempDB（ソリッドステート）
私の開発者：
- Hyper-VがホストするSQL ServerおよびDynamics AX 2012 AOSサーバー
- ハイパースレッディングを備えたCore i7 3.4ghz（8論理コア）
- 8GBのメモリ
- Windows Server 2008 R2
- VM全体のSSD。
探している他の事柄に関する意見を歓迎します。