AzureSQLデータベースで高いWRITELOG待機

Aug 18 2020

Azure SQLデータベースのWaitStats分析では、最大待機のカウンターとしてWRITELOGとHADR_SYNC_COMMITが表示されています。これはPremium250eDTUリソースです。

脚本

SELECT   TOP (10) wait_type,
                  CAST (([wait_time_ms] / 1000.0) AS DECIMAL (16, 2)) AS [WaitS],
                  CAST (100.0 * [wait_time_ms] / SUM([wait_time_ms]) OVER () AS DECIMAL (16, 2)) AS [Percentage]
FROM     sys.dm_db_wait_stats
ORDER BY [Percentage] DESC;

AZureSQLデータベースでこれに対処する方法に関する多くの情報を見つけることができません。

どんな助けでも大歓迎です。

ありがとう

回答

3 DavidBrowne-Microsoft Aug 18 2020 at 02:56

WRITELOGは、トランザクションのログレコードがディスクに強化されるのをコミットで待機し、HADR_SYNC_COMMITは、トランザクションのログレコードがネットワークを介してセカンダリレプリカに送信され、ディスクに強化されるのを待機しています。したがって、それらは非常によく似た待機です。

どちらも、アプリケーションが大量のトランザクションをコミットしていることを示しています。おそらく多すぎます。
また、プレミアムでは、ログファイルは待ち時間が非常に短いローカルフラッシュドライブ上にあるため、WRITELOGの待機が多くなると、アプリケーションで修正する必要のある問題があることがわかります。

タイトループで単一行のINSERT、UPDATE、またはDELETEを実行するプロセスがある場合は、それらを明示的なトランザクションでラップすることを検討してください。これにより、トランザクションログが最後にフラッシュされるのを待つだけで済みます。

いつものように、クエリストアは友だちであり、クエリごとの待機を表示できます。また、sys.dm_exec_session_wait_statsでセッションごとの待機を分析して、ワークロードのどの部分でこれらの待機が発生しているかを確認できます。

セッションの経過時間とCPU時間を待機時間と比較することで、クライアントが待機している時間をより正確に把握できます。例えば

select s.session_id, 
       w.wait_type, 
       w.wait_time_ms, 
       w.signal_wait_time_ms, 
       s.total_elapsed_time, 
       s.cpu_time, 
       w.wait_time_ms/cast(nullif(s.total_elapsed_time,0) as float) wait_percent_of_elapsed
from  sys.dm_exec_sessions s
join sys.dm_exec_session_wait_stats w
  on s.session_id = w.session_id
where w.wait_time_ms > 0
order by wait_percent_of_elapsed desc