HADR_SYNC_COMMITの奇妙なケースが待機する

私たちはHADR_SYNC_COMMIT、私たちの環境での待機の興味深いパターンに気づいています。3つのレプリカがあります。1つのプライマリ、1つの同期セカンダリ、および1つの非同期セカンダリがデータセンターにあり、さらに3つのASYNCレプリカを別のデータセンター（約2400マイル離れた場所）に追加しました。

それ以来、HADR_SYNC_COMMIT待機の大幅な増加に気づき始めました。アクティブなセッションを見るCOMMIT TRANSACTIONと、SYNCレプリカで待機しているクエリがたくさんあります

スクリーンショットから、HADR_SYNC_COMMIT6月29日に待機が急増していることがはっきりとわかります。最終的に、7月1日の正午に、リモートデータセンターの3つの非同期レプリカのうち「2つ」をドロップしました。これにより、待ち時間も大幅に減少しました。

これまでに確認したこと–リモートレプリカのログ送信キュー、やり直しキュー、最終強化時間、最終コミット時間。営業時間中に小さなトランザクションのバーストが連続しているため、送信キューは特定のタイムスタンプ（60KBから1MBの間）でかなり小さくなっています。
リモートレプリカはほぼ同期しています。レプリカ上の個々のlsnの最終コミット時刻と最終硬化時刻の差はほとんどありません。

ネットワークパイプは10Gであり、送信バッファーサイズを256 MBから2 GBに変更しました。これは、ネットワークがパケットをドロップして再送信しているという前提の下で行われました。どちらの方法でもあまり役に立たないようです。

では、ASYNCレプリカはHADR_SYNC_COMMIT待機とどう関係しているのでしょうか。SYNCレプリカはこの待機タイプに単独で依存するべきではありません。ここで何が欠けていますか？

sql-server sql-server-2014

— アルン・ゴピナース
ソース

実際に問題はありますか？多くの人々はただ彼らの待機を見て、「ちょっと、これは最高の待機です、それは問題になるに違いありません！」と言うだけです。待機は単なる数値であり、常に最大の数値を持つものがあります-必ずしも解決すべきパフォーマンスの問題があることを意味するわけではありません。特にこの待ち時間のために、それはあなたが外に支配してきたと思われる最も一般的な原因、そしてあなたのセカンダリが遅れていないので、私はこの「問題」になるまでに多くのエネルギーを費やすないだろう

— アーロン・ベルトラン

待機カウンターの数値が高い他の症状があり、高い待機カウンターと相関関係がある可能性があります。

— アーロンバートランド

@AaronBertrandはい、あります。プライマリレプリカのアクティブなspidは、同期セカンダリでログブロックが強化されるのを待機します。この遅延/待機により、アプリケーションの速度が大幅に低下します。スクリーンショットに表示されているpagelatch_upが7月9日に待機するのは、tempdbの競合（pfsページで待機する）が原因でした。dba側からさらにファイルを追加し、アプリケーションスタッフは、この問題を軽減するためにtempdbに頻繁にヒットするストアドプロシージャを調整しました。hadr_sync_waitsに戻ると、なぜ非同期コミットが最初からhadr_sync_commitsに影響するのですか？ありがとう。

— アルンゴピナース2015

待機時間には転送時間が含まれ、データは一緒に転送されると思いますが、非同期はコミットACKを待つ必要はありません。したがって、同期または非同期に関係なく、セカンダリの数が増えるほど、ログアクティビティの転送に費やされる時間が長くなります（これは、一部が同時に発生する可能性があるため、必ずしもクロック時間とは限りません）。ネットワーク担当者に、一般的に、またはセカンダリを追加するときに、過度のレイテンシが発生していないかどうかを確認してもらいたい場合があります。

— アーロンバートランド

まず、質問に関する待機イベントの説明は次のとおりです。

同期されたセカンダリデータベースのトランザクションコミット処理がログを強化するのを待っています。この待機は、Transaction Delayパフォーマンスカウンターにも反映されます。この待機タイプは、同期された可用性グループで想定され、セカンダリデータベースへのログの送信、書き込み、および確認の時間を示します。

https://msdn.microsoft.com/en-us/library/ms179984.aspx

この待機のメカニズムを掘り下げると、リモートサーバーでログブロックが送信されて強化されますが、回復は完了しません。これが事実であり、追加のレプリカを追加した場合、帯域幅要件の増加によりHADR_SYNC_COMMITが増加する可能性があります。この場合、Aaron Bertrandは質問に対する彼のコメントで正確です。

ソース：http : //blogs.msdn.com/b/psssql/archive/2013/04/26/alwayson-hadron-learning-series-hadr-sync-commit-vs-writelog-wait.aspx

この待機がアプリケーションのスローダウンにどのように関係しているのかについての質問の2番目の部分を掘り下げます。これは因果関係の問題だと思います。あなたは待機が増え、最近のユーザーの苦情を見て、これがまったく当てはまらない可能性がある場合に2つが関係を持っているという潜在的に誤った結論を導き出しています。tempdbファイルを追加し、アプリケーションの応答性が向上したという事実は、データベースが可用性グループにあるときに、暗黙的なスナップショット分離レベルのオーバーヘッドの追加のオーバーヘッドによって悪化した可能性のある、根本的な競合の問題があったことを示しています。これは、HADR_SYNC_COMMITの待機とはほとんど関係がない可能性があります。

これをテストする場合は、プライマリレプリカのhadr_db_commit_mgr_update_harden XEventを調べる拡張イベントトレースを利用して、ベースラインを取得できます。ベースラインを取得したら、レプリカを一度に1つずつ追加して、トレースがどのように変化するかを確認できます。データベースを含まないボリュームにあるファイルを使用し、ロールオーバーと最大サイズを設定することを強くお勧めします。必要に応じて期間フィルターを調整し、待機と一致するイベントを収集して、これをさらにトラブルシューティングし、関与する必要がある他のチームと関連付けることができるようにしてください。

CREATE EVENT SESSION [HADR_SYNC_COMMIT-Monitor] ON SERVER  -- Run this on the primary replica 
ADD EVENT sqlserver.hadr_db_commit_mgr_update_harden(
    WHERE ([delay]>(10))) -- I strongly encourage you to use the delay filter to avoid getting too many events back, this is measured in milliseconds
ADD TARGET package0.event_file(SET filename=N'<YourFilePathHere>')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=OFF,STARTUP_STATE=OFF)
GO

— トラビスページ
ソース