現在、監視ツールを使用して、待機タスクの数または合計待機時間のいずれかで上位の待機統計を表示しています。以下は、待機中のタスク数ごとの待機統計と、タスクごとの待機時間です。
システムの速度低下を訴えるユーザーがいますが、サーバーのメトリックはディスクIO、メモリ、およびCPUの点で問題がないようです。 PREEMPTIVEの待機が問題であるかどうか誰かが知っていますか?
Number of waiting tasks
SOS_SCHEDULER_YIELD
PAGELATCH_EX
PAGELATCH_SH
PREEMPTIVE_XE_CALLBACKEXECUTE
PREEMPTIVE_XE_GETTARGETSTATE
PREEMPTIVE_XE_SESSIONCOMMIT
Average wait per task
PAGEIOLATCH_SH
PREEMPTIVE_XE_GETTARGETSTATE
更新:
私はあなたが投稿したものと同様のクエリをPaul Randalから実行し、次のものを得ました:
WaitType Wait_S Resource_S Signal_S WaitCount Percentage AvgWait_S AvgRes_S AvgSig_S
PREEMPTIVE_XE_GETTARGETSTATE 9704.81 9704.81 0.00 604647 44.60 0.0161 0.0161 0.0000
私はこれがうまく整列しないことを知っていますが、基本的にこの待機タイプはすべての待機タイプの%44.60を占めています。また、このタイプではシグナル待機がなかったため、これはCPUのプレッシャーではなく、他のリソースでの待機を示しています。しかし、そのリソースが何であるかをどのように推測するのかわかりません。
また、これはSQL 2012 SP1です。
pdate2ここで要求されるASは、クエリの結果です。拡張イベントに関しては、実行中の唯一のセッションはデフォルトのsystem_healthと2つ前に気づいたSharePointのものです。これらはデフォルトでそこに配置されている必要があります。これらが問題を引き起こしているのではないかと思います。
私のPREEMPTIVE_XE_GETTARGETSTATEがこのリストにないように見えるのは興味深いことです。
wait_type wait_time_ms signal_wait_time_ms resource_wait_time_ms percent_total_waits percent_total_signal_waits percent_total_resource_waits
SP_SERVER_DIAGNOSTICS_SLEEP 300014 355508314 0 24.621089361251698 99.883069863550302 0.000000000000000
MSQL_XP 96782 0 4268999 0.295653861591811 0.000000000000000 0.295653861591811
ASYNC_IO_COMPLETION 56193 64 345552 0.023935987107964 0.000017981341700 0.023931554722962
BACKUPTHREAD 41100 6850 265025 0.018828979257262 0.001924565478840 0.018354575549998
LCK_M_U 40500 71 41030 0.002846491499596 0.000019948050948 0.002841574322484
PWAIT_ALL_COMPONENTS_INITIALIZED 31422 0 94205 0.006524262955146 0.000000000000000 0.006524262955146
XE_LIVE_TARGET_TVF 28050 0 33458 0.002317167771915 0.000000000000000 0.002317167771915
LCK_M_X 4027 50 29195 0.002025392177944 0.000014047923203 0.002021929377161
SQLTRACE_INCREMENTAL_FLUSH_SLEEP 4018 613 355390660 24.612983567922965 0.000172227538471 24.612941113985366
CXPACKET 3756 1 14755 0.001021941767062 0.000000280958464 0.001021872511047
SQL Serverは非優先モードで動作します。つまり、Windows OSから要求を受け取ったためにSQLOSがそれを要求した場合、SQL Serverは要求を受け取り、SQL Serverはそれを待機して、SQLOSが要求したとおりに要求または実行します。 。これは、SQLサーバーがアプリケーションとして実行され、Windows Oによって監視されるSQLOSによってリソースが割り当てられるためです。SQLサーバーがタスクを実行し、OSによって中断され、使用可能なスレッドを放棄して、他のタスクに割り当てられ、SQLがそれを行います。待機し、スレッドが使用可能になるまで待機します。この待機はPREEMTIVE-XXX待機になります。
ここでSQLサーバーのバージョンとは、最新のサービスパックにパッチが適用されているということです。SQLサーバー2008にバグがあり、これは予測待機タイプの誤った値を示しています。
sys.dm_exec_requests DMVを実行して、模範的な待機タイプを取得するプロセスが一時停止または実行されているかどうかを確認できますか?.
以下のクエリの出力(Jonathan Kehayiasによる)を投稿して、待機統計をキャプチャしてください。
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',
'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 DES
システムで他にどのようなプロセスが実行されていますか?OSは負荷がかかっていますか?システムにはCPUコアがいくつありますか?
編集:ユーザーが出力を貼り付けた後
出力は与えません、そして具体的な写真は私のクエリを使用します。また、XE待機タイプを確認できるため、拡張イベントトレースを実行していますか。私はこの待機タイプを有害と見なしており、問題に直面していないようです。監視ツールは時々overreactなので、あなたが投稿した結果は、その通常の動作だと思います。
EDIT2:私はあなたが投稿した待機統計出力に問題を見つけません。私はまたあなたのサーバーが最近再起動されなかったと思います、さもなければ待機統計は役に立ちません。
preemptive_xe_*
待機タイプは、私が理解して見つけた拡張イベントに関連付けられています。それとあなたの最初の文を考慮してください:
現在、監視ツールを使用して、待機タスクの数または合計待機時間のいずれかで上位の待機統計を表示しています。
私はあなたの監視ツールを犯人と見なし始めます。ただし、Paulのスクリプトからのデータが平均待機時間が少ないことを示しているため、現時点ではあまり考慮しません。
あなたが見落としているかもしれないと私が思うここでのあなたの主な挑戦は、ユーザーがシステム/アプリケーションでスローダウンがあったとあなたに言われたことです。ほとんどの場合、常にデータベース/サーバーが原因となっています。誰かが「システムのどの部分が遅い」と私に言ったときの私の一般的な次の質問。ページの読み込みが遅いなどの問題があり、アドホックレポートやクエリを実際に実行していない場合は、サーバースタッフまたはアプリケーション管理者に確認して、他に問題がないことを確認してもらいます。次に、その間にデータベースサーバーのパフォーマンスを確認します。ただし、XE待機タイプが10%を超えるのが1つだけかどうかを示したように、データベースサーバーに問題があるとは思いません。
その待機タイプの原因を見つけたい場合は、sys.dm_os_waitting_tasks
のクエリを開始できます。これにより、session_id
が表示され、発生するまで待機します。 sp_WhoIsActive を使用して、同様の情報をもう少し簡単に取得することもできます。あなたの監視ツールに関連付けられたセッションであることがわかると思います。
PreEmptive_XXX
待機タイプは次のとおりです。
ワーカーがSQLOSスケジューリングシステムの下にないコードを実行していることを示すために使用されます
したがって、本質的にSQL Serverは、独自の処理を続行する前に、外部プロセスが完了するのを待機しています。
これはCLRまたは拡張ストアドプロシージャの使用が原因で発生する可能性があるので、これらのいずれかを使用している場合は、まずそこから調べます。