私は、SQLサーバーのパフォーマンスの問題について、DBAとハードウェアの何人かと議論してきました。通常はすべて問題ありませんが、過去数週間に渡ってSQLサーバーで大幅な遅延スパイクが発生しています。 SQL ServerがディスクI/Oを待機していることは明らかです。しかし、SQL Serverが異常に高いI/Oを要求しているのは理由だと言われ続けています。そうではありません。何が実行されているかを確認すると、正常なものは何もないことがわかります。DBAが注意しなければならないのは、ブロッキングを引き起こしている原因などであり、これは役に立ちません。たとえば、バックアップの主な内容は、ASPStateデータベースでの操作です。これは、WebサーバーでASPセッション状態を管理するために使用しています。これらの操作は、通常、Sp_who2のアクティブな結果では表示されません。それらは非常に迅速に発生するためです。データベースはシンプルリカバリモードであり、ロギングはわずかです。しかし、これらのラグスパイクの間に、ブロックまたは待機中のデータベースでの選択および更新操作の多くを見ることができます。または、そのデータベースログとデータファイルに使用されているRAIDアレイでディスクの使用量が多い原因となっている何かがジョブによって実行されています。Webサイトを破壊していることをしていると認めたくないので、問題はそれを証明しています。
私の質問は、SQLサーバーがI/Oを待機していることを示すために役立つパフォーマンスカウンターまたはログに何を記録できるかですが、通常よりも要求が多いためではなく、SQLサーバーからの要求に応答するためにディスクがビジーであるためです通常より早く?
以下のperfmonカウンターをご覧ください。
Page lookups/sec
Page reads/sec
Readahead pages/sec
Full Scans/sec
Range Scans/sec
Skipped Ghosted Records/sec
Page IO latch waits
多数のIO要求を駆動するSQL Serverは、多数のスキャンで確証され、ページルックアップとページ読み取りが増加し、高ページIOラッチ待機します。見てみる価値があります sys.dm_exec_query_stats
物理読み取り数が多いエントリの場合。彼らはすぐに犯人を特定できた。
一般に、パフォーマンスのトラブルシューティングの問題として問題にアプローチする場合、 Waits and Queues のような方法論に従うことが正しいアプローチです。あなたのDBAは正しいことをしているようですので、彼の話を聞いてください。
Glenn Berryの 診断クエリ とAdam Machanicの SP_Whoisactive を使用して、実際に何が起こっているのかを調べます。
最初に、このクエリを実行して、どのデータベースファイルが最も多くのIOボトルネックになっているのかを確認します(Glenn Berryによるクエリ)。
SELECT DB_NAME(fs.database_id) AS [Database Name] ,
mf.physical_name ,
io_stall_read_ms ,
num_of_reads ,
CAST(io_stall_read_ms / ( 1.0 + num_of_reads ) AS NUMERIC(10, 1)) AS [avg_read_stall_ms] ,
io_stall_write_ms ,
num_of_writes ,
CAST(io_stall_write_ms / ( 1.0 + num_of_writes ) AS NUMERIC(10, 1)) AS [avg_write_stall_ms] ,
io_stall_read_ms + io_stall_write_ms AS [io_stalls] ,
num_of_reads + num_of_writes AS [total_io] ,
CAST(( io_stall_read_ms + io_stall_write_ms ) / ( 1.0 + num_of_reads
+ num_of_writes ) AS NUMERIC(10,
1)) AS [avg_io_stall_ms]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf WITH ( NOLOCK ) ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]
ORDER BY avg_io_stall_ms DESC
OPTION ( RECOMPILE );
次に、このクエリを実行して、サーバーが待機しているイベントのトップ10を確認します(query by Jonathan Kehayias )。 Glenn Berryの診断クエリから同様のクエリも見つかります。
SELECT TOP 10
wait_type ,
max_wait_time_ms wait_time_ms ,
signal_wait_time_ms ,
wait_time_ms - signal_wait_time_ms AS resource_wait_time_ms ,
100.0 * wait_time_ms / SUM(wait_time_ms) OVER ( ) AS percent_total_waits ,
100.0 * signal_wait_time_ms / SUM(signal_wait_time_ms) OVER ( ) AS percent_total_signal_waits ,
100.0 * ( wait_time_ms - signal_wait_time_ms )
/ SUM(wait_time_ms) OVER ( ) AS percent_total_resource_waits
FROM sys.dm_os_wait_stats
WHERE wait_time_ms > 0 -- remove zero wait_time
AND wait_type NOT IN -- filter out additional irrelevant waits
( 'SLEEP_TASK', 'BROKER_TASK_STOP', 'BROKER_TO_FLUSH', 'SQLTRACE_BUFFER_FLUSH',
'CLR_AUTO_EVENT', 'CLR_MANUAL_EVENT', 'LAZYWRITER_SLEEP', 'SLEEP_SYSTEMTASK',
'SLEEP_BPOOL_FLUSH', 'BROKER_EVENTHANDLER', 'XE_DISPATCHER_WAIT',
'FT_IFTSHC_MUTEX', 'CHECKPOINT_QUEUE', 'FT_IFTS_SCHEDULER_IDLE_WAIT',
'BROKER_TRANSMITTER', 'FT_IFTSHC_MUTEX', 'KSOURCE_WAKEUP',
'LAZYWRITER_SLEEP', 'LOGMGR_QUEUE', 'ONDEMAND_TASK_QUEUE',
'REQUEST_FOR_DEADLOCK_SEARCH', 'XE_TIMER_EVENT', 'BAD_PAGE_PROCESS',
'DBMIRROR_EVENTS_QUEUE', 'BROKER_RECEIVE_WAITFOR',
'PREEMPTIVE_OS_GETPROCADDRESS', 'PREEMPTIVE_OS_AUTHENTICATIONOPS', 'WAITFOR',
'DISPATCHER_QUEUE_SEMAPHORE', 'XE_DISPATCHER_JOIN', 'RESOURCE_QUEUE' )
ORDER BY wait_time_ms DESC
この情報を入手すると、問題のトラブルシューティングがはるかに簡単になります。
ところで、トラブルシューティングにsp_whoisactiveを使用する方法に関する多くの投稿を見つけることができます こちら
「問題はそれを証明している」と正しく言った。 SQL Server:Minimize Disk I/O を見てください。
次のDMVについて話している
sys.dm_io_virtual_file_stats
sys.dm_io_pending_io_requests
参考文献: