次の方法で共有

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

  • [アーティクル]

適用対象:Azure SQL データベース

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

ログ レートの待機時間の短縮

Azure SQL Database 内のすべてのデータベースとエラスティック プールは、ログレートガバナンス使用してログ生成率を管理します。 Hyperscale では、コンピューティング サイズに関係なく、ログ レートのガバナンス制限は 105 MB/秒に設定されます。 この値は、primary_max_log_rate の 列で公開されます。

場合によっては、回復性 SLA を維持するために、プライマリ コンピューティング レプリカのログ生成率を減らす必要があります。 たとえば、ページ サーバーまたは別のコンピューティング レプリカ が、ログ サービスから新しいログ レコードを適用するかなり遅れている場合に発生する可能性があります。 ハイパースケール コンポーネントが背後に存在しない場合、ログ レート ガバナンス メカニズムを使用すると、ログ生成速度が 100 MB/秒に達します。 これは、すべての Hyperscale コンピューティング サイズにおける有効な最大ログ生成率です。

Note

オプトイン プレビュー機能として、150 MB/秒のログ生成率を使用できます。 詳細および 150 MB/秒へのオプトインについては、ブログ: 2024 年 11 月のハイパースケール機能強化を参照してください。

ログ レートが低下すると、sys.dm_os_wait_stats に次の待機の種類が表示されます。

待機の種類 理由
RBIO_RG_STORAGE ページ サーバーによるログ使用の遅延
RBIO_RG_DESTAGE 長期ログストレージによるログ消費の遅延
RBIO_RG_REPLICA HA セカンダリ レプリカまたは名前付きレプリカによるログ使用の遅延
RBIO_RG_GEOREPLICA ジオセカンダリ レプリカによるログ使用の遅延
RBIO_RG_DESTAGE ログ サービスによるログの処理の遅延
RBIO_RG_LOCALDESTAGE ログサービスによるログ消費の遅延
RBIO_RG_STORAGE_CHECKPOINT データベース チェックポイントが遅いため、ページ サーバーによるログの使用が遅い
RBIO_RG_MIGRATION_TARGET 逆移行中の Hyperscale 以外のデータベースによるログの使用の遅延

sys.dm_hs_database_log_rate() 動的管理機能 (DMF) には、ログ レートの低下 (ある場合) を理解するのに役立つ追加の詳細が用意されています。 たとえば、ログ レコードの適用の背後にある特定のセカンダリ レプリカと、まだ適用されていないトランザクション ログの合計サイズを確認できます。

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

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

コンピューティング レプリカで読み取り IO が発行されると、データがバッファー プールまたはローカル SSD キャッシュに存在しない場合、要求された ログ シーケンス番号 (LSN) のページが、対応するページ サーバーからフェッチされます。 ページ サーバーからの読み取りはリモートであり、ローカル SSD キャッシュからの読み取りよりも低速です。 I/O 関連のパフォーマンスの問題をトラブルシューティングする場合は、比較的低速なページ サーバー読み取りを使用して実行された 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 に存在します。 例えば：
    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    ヒント

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

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

Azure SQL Database では、sys.dm_io_virtual_file_stats() DMF は、IOPS、スループット、待機時間などのデータベース I/O 統計を監視する 1 つの方法です。 Hyperscale の I/O 特性は、分散アーキテクチャのにより異なります。 このセクションでは、この DMF で見られるように、読み取りと書き込みの I/O に焦点を当てます。 Hyperscale では、この DMF に表示される各データ ファイルはページ サーバーに対応します。 DMF は、コンピューティング レプリカ上のローカル SSD キャッシュとトランザクション ログの I/O 統計も提供します。

ローカル SSD キャッシュの使用状況

ローカル SSD キャッシュは、データベース エンジンがクエリを処理しているのと同じコンピューティング レプリカ上に存在するため、このキャッシュに対する I/O はページ サーバーに対する I/O よりも高速です。 Hyperscale データベースまたはエラスティック プールでは、sys.dm_io_virtual_file_stats() には、ローカル SSD キャッシュの I/O 統計を報告する特別な行があります。 この行には、database_id 列と file_id 列の両方の 0 の値があります。 たとえば、次のクエリでは、データベースの起動以降のローカル SSD キャッシュ I/O 統計が返されます。

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

ローカル SSD キャッシュからの読み取りと他のすべてのデータ ファイルからの集計読み取りの比率は、ローカル SSD キャッシュ ヒット率です。 このメトリックは、sys.dm_os_performance_counters DMV で使用できる RBPEX cache hit ratio および RBPEX cache hit ratio base パフォーマンス カウンターによって提供されます。

データ読み取り

  • データベースエンジンがコンピュートレプリカ上で読み取りを発行する際、ローカルSSDキャッシュやページサーバー、または複数ページの読み取り時にはそれら二つの組み合わせから提供される可能性があります。
  • コンピューティング レプリカが特定のデータ ファイル (たとえば、file_id 1 のファイル) からいくつかのページを読み取る場合、このデータがローカル SSD キャッシュにのみ存在する場合、この読み取りのすべての IO は file_id 0 に対して考慮されます。 そのデータの一部がローカル SSD キャッシュ内にあり、一部がページ サーバー上にある場合、IO はローカル SSD キャッシュから提供されるパーツの file_id 0 に対して考慮され、ページ サーバーから提供されるパーツは対応するファイルに対して考慮されます。
  • コンピューティング レプリカがページ サーバーから特定の LSN のページを要求した場合、ページ サーバーが要求された LSN にまだ追いついていない場合、コンピューティング レプリカの読み取りは、ページ サーバーがキャッチアップするまで待機してからページが返されます。 コンピューティング レプリカにあるページ サーバーから読み込む際、その IO を待っているときには、PAGEIOLATCH_* 待機タイプが表示されます。 Hyperscale では、この待機時間には、ページサーバー上の要求されたページを必要なLSNに追いつくための時間と、ページサーバーからコンピューティング レプリカにページを転送するために必要な時間の両方が含まれます。
  • 先読みなどの大規模な読み取り操作は、多くの場合、散布・収集読み取り技術を使用して行われます。 これにより、1 回の読み取り IO として最大 4 MB の読み取りが可能になります。 ただし、読み取るデータがローカル SSD キャッシュにある場合、バッファー プールとローカル SSD キャッシュでは常に 8 KB のページが使用されるため、これらの読み取りは複数の個別の 8 KB 読み取りとして考慮されます。 その結果、ローカル SSD キャッシュに対して表示される読み取り IO の数が、エンジンによって実行された IO の実際の数よりも多くなることがあります。

データ書き込み

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

ログ書き込み

  • プライマリ コンピューティング レプリカでは、ログ書き込みは file_id 2 の下で sys.dm_io_virtual_file_stats() に記録されます。
  • AlwaysOn 可用性グループとは異なり、プライマリ コンピューティング レプリカでトランザクションがコミットされると、セカンダリ レプリカでログ レコードは強化されません。 Hyperscale では、ログはログ サービスで強化され、セカンダリ レプリカに非同期的に適用されます。 ログの書き込みは実際にはセカンダリ レプリカでは行われませんので、セカンダリ レプリカの sys.dm_io_virtual_file_stats() のログ IO をトランザクション ログ I/O 統計として使用しないでください。

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

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

Hyperscale データベースでは、これらの列とメトリックは、ローカル SSD キャッシュと tempdb データベースに対する I/O を含む、コンピューティング レプリカ上のローカル SSD ストレージの制限に対するデータ IOPS 使用率に関して報告します。 この列の100% 値は、リソース ガバナンスがローカル ストレージの IOPS を制限していることを示します。 これがパフォーマンスの問題と関連している場合は、ワークロードを調整して生成する IO を減らすか、コンピューティング サイズを大きくして、最大データ IOPS制限リソース ガバナンスを増やします。 ローカル SSD キャッシュの読み取りと書き込みのリソース ガバナンスでは、データベース エンジンによって発行される可能性がある大規模な IO ではなく、個々の 8 KB IO がカウントされます。

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

関連コンテンツ