SQL Hyperscale のパフォーマンスのトラブルシューティング診断

[アーティクル]
08/16/2024

Hyperscale データベースでのパフォーマンスの問題のトラブルシューティングを行うには、Azure SQL Database の計算ノードに対する一般的なパフォーマンスのチューニング方法が、パフォーマンス調査の開始点となります。ただし、Hyperscale の分散アーキテクチャを考慮して、追加の診断データを検討する必要があることがあります。この記事では、Hyperscale 固有の診断データについて説明します。

ログ速度調整の待機

すべての Azure SQL Database サービス目標には、ログ速度ガバナンスによって適用されるログ生成速度制限があります。 Hyperscale では、サービスレベルに関係なく、ログガバナンスの上限は 105 MB/秒に設定されます。この値は、sys.dm_user_db_resource_governance の primary_max_log_rate 列で公開されます。

ただし、復元可能性 SLA を維持するために、プライマリコンピューティングレプリカのログ生成速度を調整する必要がある場合もあります。この調整は、ページサーバーまたは別のコンピューティングレプリカが、ログサービスからの新しいログレコードの適用で大幅に遅れている場合に発生します。遅れているページサーバーまたはレプリカがない場合、調整メカニズムにより、ログ生成レートは 100 MB/s に達します。これは、すべての Hyperscale サービス目標で効果的な最大ログ生成レートです。オプトインプレビュー機能として、150 MB/秒のログ生成率を使用できます。詳細および 150 MB/秒へのオプトインについては、ブログ: 2024 年 11 月のハイパースケール機能強化を参照してください。

次の待機の種類 (sys.dm_os_wait_stats 内) は、プライマリコンピューティングレプリカでログ速度を調整できる理由を示しています。

待機の種類	説明
RBIO_RG_STORAGE	1 つ以上のページサーバーでのログ使用の遅延が原因で Hyperscale データベースのプライマリ計算ノードのログ生成速度が調整されているときに発生します。
RBIO_RG_DESTAGE	長期ログストレージによるログ使用の遅延が原因で Hyperscale データベースの計算ノードのログ生成速度が調整されているときに発生します。
RBIO_RG_REPLICA	1 つ以上の読み取り可能なセカンダリレプリカによるログ使用の遅延が原因で、Hyperscale データベースの計算ノードのログ生成速度が調整されているときに発生します。
RBIO_RG_GEOREPLICA	geo セカンダリレプリカによるログ使用の遅延が原因で、Hyperscale データベースの計算ノードのログ生成速度が調整されているときに発生します。
RBIO_RG_LOCALDESTAGE	ログサービスによるログ使用の遅延が原因で Hyperscale データベースの計算ノードのログ生成速度が調整されているときに発生します。

ページサーバーの読み取り

コンピューティングレプリカでは、データベースの完全なコピーがローカルにキャッシュされません。コンピューティングレプリカにローカルなデータはバッファープール (メモリ内) と、データページの部分的な (カバーされていない) キャッシュであるローカル RBPEX (弾性バッファープール拡張機能) キャッシュに格納されます。このローカル RBPEX キャッシュは、コンピューティングサイズに比例してサイズが調整され、コンピューティングレベルのメモリの 3 倍となります。 RBPEX は、最も頻繁にアクセスされるデータが含まれているという点でバッファープールに似ています。一方、各ページサーバーには、保持するデータベースの部分をカバーする RBPEX キャッシュがあります。

コンピューティングレプリカに対して読み取りが発行されると、バッファープールまたはローカル RBPEX キャッシュにデータが存在しない場合は、getPage(pageId, LSN) 関数呼び出しが発行され、対応するページサーバーからそのページがフェッチされます。ページサーバーからの読み取りはリモート読み取りであるため、ローカル RBPEX からの読み取りよりも低速です。 IO 関連のパフォーマンスの問題のトラブルシューティングを行うときは、比較的低速なリモートページサーバー読み取りによって IO が何回実行されたのかを把握できる必要があります。

いくつかの DMV (Dynamic Managed View) および拡張イベントには、ページサーバーからのリモート読み取りの数を指定する列とフィールドがあり、この数を合計読み取り数と比較できます。クエリストアでは、クエリ実行時間の統計の一部として、リモート読み取りもキャプチャされます。

ページサーバー読み取りをレポートする列は、実行 DMV およびカタログビューで利用でき、次のようなものがあります。
ページサーバー読み取りは、次の拡張イベントに追加されます。
- sql_statement_completed
- sp_statement_completed
- sql_batch_completed
- rpc_completed
- scan_stopped
- query_store_begin_persist_runtime_stat
- query-store_execution_runtime_info
ActualPageServerReads/ActualPageServerReadAheads が、実際のプランのクエリプラン XML に追加されます。次に例を示します。

Note

クエリプランのプロパティウィンドウでこれらの属性を表示するには、SSMS 18.3 以降が必要です。

仮想ファイルの統計と IO アカウンティング

Azure SQL Database では、SQL Database IO を監視する主な方法は、sys.dm_io_virtual_file_stats() DMF です。 Hyperscale の IO 特性は、その分散アーキテクチャによって異なります。このセクションでは、この DMF で表示されるデータファイルへの IO (読み取りと書き込み) に焦点を当てます。 Hyperscale では、この DMF で表示される各データファイルは、1 つのリモートページサーバーに対応します。ここで説明する RBPEX キャッシュは、コンピューティングレプリカ上でカバーされていないキャッシュである SSD ベースのローカルキャッシュです。

ローカル RBPEX キャッシュの使用

ローカル RBPEX キャッシュは、ローカル SSD ストレージの計算レプリカ上に存在します。そのため、このキャッシュの IO は、リモートページサーバーの IO より高速です。現在、Hyperscale データベースの sys.dm_io_virtual_file_stats() には、コンピューティングレプリカのローカル RBPEX キャッシュに対して実行された IO を報告する特別な行があります。この行の database_id と file_id の両方の列の値は 0 です。たとえば、次のクエリでは、データベースの起動以降の RBPEX 使用状況の統計が返されます。

select * from sys.dm_io_virtual_file_stats(0,NULL);

RBPEX で実行された読み取りと、他のすべてのデータファイルに対して行われた集約読み取りとの比率から、RBPEX キャッシュヒット率が得られます。カウンター RBPEX cache hit ratio は、パフォーマンスカウンター DMV sys.dm_os_performance_counters でも公開されています。

データ読み取り

コンピューティングレプリカ上の SQL Server データベースエンジンによって読み取りが発行されると、それらの読み取りは、ローカル RBPEX キャッシュかリモートページサーバー、または複数のページから読み取る場合はこの 2 つの組み合わせによって処理される可能性があります。
コンピューティングレプリカが特定のファイル (file_id 1 など) から一部のページを読み取るとき、このデータがローカル RBPEX キャッシュにのみ存在する場合、この読み取りのすべての IO は file_id 0 (RBPEX) に対するものと見なされます。そのデータの一部がローカル RBPEX キャッシュにあり、一部がリモートページサーバーにある場合、IO は、RBPEX から提供される部分については file_id 0 に対するものと見なされ、リモートページサーバーから提供される部分については file_id 1 に対するものと見なされます。
コンピューティングレプリカがページサーバーから特定の LSN でページを要求したときに、ページサーバーが、要求された LSN に追いついていない場合、コンピューティングレプリカでの読み取りは、ページサーバーが追いつくまで待機してから、そのページがコンピューティングレプリカに返されます。コンピューティングレプリカでのページサーバーからの読み取りでは、その IO で待機している場合、PAGEIOLATCH_* の待機の種類が表示されます。 Hyperscale では、この待機時間には、ページサーバー上の要求されたページを必要なLSNに追いつくための時間と、ページサーバーからコンピューティングレプリカにページを転送するために必要な時間の両方が含まれます。
先読みなどの大規模な読み取りは、多くの場合、"スキャッター/ギャザー" 読み取りを使用して行われます。これにより、一度に最大 4 MB のページの読み取りが可能になります。これは、SQL Server データベースエンジンでの 1 回の読み取りと見なされます。ただし、読み取り中のデータが RBPEX に存在する場合、バッファープールと RBPEX で常に 8 KB のページが使用されるため、これらの読み取りは複数の個別の 8 KB の読み取りと見なされます。その結果、RBPEX に対して表示される読み取り IO の数が、エンジンによって実行された実際の IO 数よりも大きくなる場合があります。

データ書き込み

プライマリコンピューティングレプリカは、ページサーバーに直接書き込みません。代わりに、ログサービスからのログレコードは対応するページサーバーで再生されます。
コンピューティングレプリカで発生する書き込みは、主にローカル RBPEX (file_id 0) に書き込まれます。 8 KB を超える論理ファイルの書き込み (つまり、ギャザー書込みを使用して実行されるもの) では、バッファープールと RBPEX は常に 8 KB のページを使用するため、各書き込み操作は RBPEX への複数の 8 KB の個別書き込みに変換されます。その結果、RBPEX に対して表示される書き込み IO の数が、エンジンによって実行された実際の IO 数よりも大きくなる場合があります。
RBPEX 以外のファイル、またはページサーバーに対応する file_id 0 以外のデータファイルにも、書き込み回数が表示されます。 Hyperscale サービスレベルでは、コンピューティングレプリカがページサーバーに直接書き込むことはないため、これらの書き込みはシミュレートされます。書き込み IOPS とスループットは、コンピューティングレプリカで発生すると見なされますが、file_id 0 以外のデータファイルの待機時間は、ページサーバーの書き込みの実際の待機時間を反映しません。

ログ書き込み

プライマリコンピューティングでは、ログ書き込みは sys.dm_io_virtual_file_stats の file_id 2 に相当します。プライマリコンピューティングでのログ書き込みは、ログランディングゾーンへの書き込みです。
ログレコードは、セカンダリレプリカにはコミット時に書き込まれません。 Hyperscale では、ログは、ログサービスによってセカンダリレプリカに非同期的に適用されます。セカンダリレプリカではログ書き込みが実際には発生しないため、セカンダリレプリカでのログ IO のアカウンティングはすべて、追跡のみを目的にしています。

リソース使用率の統計でのデータ IO

ハイパースケール以外のデータベースでは、データファイルに対する合計読み取り/書き込み IOPS は、リソースガバナンスデータの IOPS 制限を基準として、avg_data_io_percent 列の dm_db_resource_stats および sys.resource_stats ビューで報告されます。 Azure portal では、同じ値がデータ IO の割合として報告されます。

Hyperscale データベースでは、この列は、データ IOPS の使用率を、コンピューティングレプリカのみのローカルストレージの制限 (特に RBPEX および tempdb に対する IO) を基準として報告します。この列の100% 値は、リソースガバナンスがローカルストレージの IOPS を制限していることを示します。これがパフォーマンスの問題に関連付けられている場合は、負荷の少ない IO を生成するようにワークロードを調整するか、データベースサービスの目標値を増やして、リソースガバナンス 最大データ IOPS 制限を増やします。 RBPEX の読み取りと書き込みのリソースガバナンスでは、SQL Server データベースエンジンによって発行される可能性のあるより大きな IO ではなく、個々の 8 KB の IO がカウントされます。

リモートページサーバーに対するデータ IO は、リソース使用率ビューまたはポータルでは報告されませんが、前述のように、sys.dm_io_virtual_file_stats() DMF で報告されます。

その他のリソース

Hyperscale の単一データベースに対する仮想コアリソースの制限については、Hyperscale サービスレベルの仮想コアの制限に関する記事を参照してください
Azure SQL データベースを監視する場合は、Database Watcher を有効にします
Azure SQL Database のパフォーマンスのチューニングについては、Azure SQL Database でのクエリのパフォーマンスに関する記事を参照してください
クエリストアを使用したパフォーマンスのチューニングについては、クエリストアを使用したパフォーマンス監視に関する記事を参照してください
DMV の監視スクリプトについては、「動的管理ビューを使用して Azure SQL Database のパフォーマンスを監視する」を参照してください

次の方法で共有

SQL Hyperscale のパフォーマンスのトラブルシューティング診断

ログ速度調整の待機

ページサーバーの読み取り

仮想ファイルの統計と IO アカウンティング

ローカル RBPEX キャッシュの使用

データ読み取り

データ書き込み

ログ書き込み

リソース使用率の統計でのデータ IO

その他のリソース

フィードバック

その他のリソース

次の方法で共有

SQL Hyperscale のパフォーマンスのトラブルシューティング診断

ログ速度調整の待機

ページ サーバーの読み取り

仮想ファイルの統計と IO アカウンティング

ローカル RBPEX キャッシュの使用

データ読み取り

データ書き込み

ログ書き込み

リソース使用率の統計でのデータ IO

その他のリソース

フィードバック

その他のリソース

ページサーバーの読み取り