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

Hyperscale データベースでのパフォーマンスの問題のトラブルシューティングを行うには、Azure SQL データベースの計算ノードに対する一般的なパフォーマンスのチューニング方法が、パフォーマンス調査の開始点となります。To troubleshoot performance problems in a Hyperscale database, general performance tuning methodologies on the Azure SQL database compute node is the starting point of a performance investigation. ただし、Hyperscale の分散アーキテクチャを考慮して、役立つ診断がさらに追加されています。However, given the distributed architecture of Hyperscale, additional diagnostics have been added to assist. この記事では、Hyperscale 固有の診断データについて説明します。This article describes Hyperscale-specific diagnostic data.

ログ速度調整の待機Log rate throttling waits

すべての Azure SQL Database サービス レベルには、ログ速度ガバナンスによって適用されるログ生成速度制限があります。Every Azure SQL Database service level has log generation rate limits enforced via log rate governance. Hyperscale では、サービス レベルに関係なく、ログ生成の制限は現在 100 MB/秒に設定されています。In Hyperscale, the log generation limit is currently set to 100 MB/sec, regardless of the service level. ただし、復元可能性 SLA を維持するために、プライマリ コンピューティング レプリカのログ生成速度を調整する必要がある場合もあります。However, there are times when the log generation rate on the primary compute replica has to be throttled to maintain recoverability SLAs. この調整は、ページ サーバーまたはその他のコンピューティング レプリカがログ サービスからの新しいログ レコードの適用で大幅に遅れている場合に発生します。This throttling happens when a page server or another compute replica is significantly behind applying new log records from the Log service.

次の待機の種類 (sys.dm_os_wait_stats 内) は、プライマリ コンピューティング レプリカでログ速度を調整できる理由を示しています。The following wait types (in sys.dm_os_wait_stats) describe the reasons why log rate can be throttled on the primary compute replica:

待機の種類Wait Type [説明]Description
RBIO_RG_STORAGERBIO_RG_STORAGE ページ サーバーでのログ使用の遅延が原因で Hyperscale データベースのプライマリ 計算ノードのログ生成速度が調整されているときに発生します。Occurs when a Hyperscale database primary compute node log generation rate is being throttled due to delayed log consumption at the page server(s).
RBIO_RG_DESTAGERBIO_RG_DESTAGE 長期ログ ストレージによるログ使用の遅延が原因で Hyperscale データベースの計算ノードのログ生成速度が調整されているときに発生します。Occurs when a Hyperscale database compute node log generation rate is being throttled due to delayed log consumption by the long-term log storage.
RBIO_RG_REPLICARBIO_RG_REPLICA 読み取り可能なセカンダリ レプリカによるログ使用の遅延が原因で、Hyperscale データベースの計算ノードのログ生成速度が調整されているときに発生します。Occurs when a Hyperscale database compute node log generation rate is being throttled due to delayed log consumption by the readable secondary replica(s).
RBIO_RG_LOCALDESTAGERBIO_RG_LOCALDESTAGE ログ サービスによるログ使用の遅延が原因で Hyperscale データベースの計算ノードのログ生成速度が調整されているときに発生します。Occurs when a Hyperscale database compute node log generation rate is being throttled due to delayed log consumption by the log service.

ページ サーバーの読み取りPage server reads

コンピューティング レプリカでは、データベースの完全なコピーがローカルにキャッシュされません。The compute replicas do not cache a full copy of the database locally. コンピューティング レプリカに対してローカルなデータは、バッファー プール (メモリ内) と、データ ページの部分的な (カバーしていない) キャッシュである弾性バッファー プール拡張 (RBPEX) ローカル キャッシュに格納されます。The data local to the compute replica is stored in the Buffer Pool (in memory) and in the local Resilient Buffer Pool Extension (RBPEX) cache that is a partial (non-covering) cache of data pages. このローカル RBPEX キャッシュは、コンピューティング サイズに比例してサイズが調整され、コンピューティング レベルのメモリの 3 倍となります。This local RBPEX cache is sized proportionally to the compute size and is three times the memory of the compute tier. RBPEX は、最も頻繁にアクセスされるデータがあるという点で、バッファー プールに似ています。RBPEX is similar to the Buffer Pool in that it has the most frequently accessed data. 一方、各ページ サーバーには、保持するデータベースの部分をカバーする RBPEX キャッシュがあります。Each page server, on the other hand, has a covering RBPEX cache for the portion of the database it maintains.

コンピューティング レプリカに対して読み取りが発行されると、データがバッファー プールまたはローカル RBPEX キャッシュに存在しない場合、getPage(pageId, LSN) 関数呼び出しが発行され、対応するページ サーバーからそのページが取り込まれます。When a read is issued on a compute replica, if the data doesn't exist in the Buffer Pool or local RBPEX cache, a getPage(pageId, LSN) function call is issued, and the page is fetched from the corresponding page server. ページ サーバーからの読み取りはリモート読み取りであるため、ローカル RBPEX からの読み取りよりも低速です。Reads from page servers are remote reads and are thus slower than reads from the local RBPEX. IO 関連のパフォーマンスの問題のトラブルシューティングを行うときは、比較的低速なリモート ページ サーバー読み取りによって IO が何回実行されたのかを把握できる必要があります。When troubleshooting IO-related performance problems, we need to be able to tell how many IOs were done via relatively slower remote page server reads.

複数の DMV および拡張イベントには、列とフィールドがあり、ページ サーバーからのリモート読み取りの回数が指定されています。これを、合計読み取り数と比較できます。Several DMVs and extended events have columns and fields that specify the number of remote reads from a page server, which can be compared against the total reads. クエリ ストアでは、クエリ実行時間の統計の一部として、リモート読み取りもキャプチャされます。Query store also captures remote reads as part of the query run time stats.

  • ページ サーバー読み取りをレポートする列は、実行 DMV およびカタログ ビューで利用でき、次のようなものがあります。Columns to report page server reads are available in execution DMVs and catalog views, such as:
  • ページ サーバー読み取りは、次の拡張イベントに追加されます。Page server reads are added to the following extended events:
    • sql_statement_completedsql_statement_completed
    • sp_statement_completedsp_statement_completed
    • sql_batch_completedsql_batch_completed
    • rpc_completedrpc_completed
    • scan_stoppedscan_stopped
    • query_store_begin_persist_runtime_statquery_store_begin_persist_runtime_stat
    • query-store_execution_runtime_infoquery-store_execution_runtime_info
  • ActualPageServerReads/ActualPageServerReadAheads が、実際のプランのクエリ プラン XML に追加されます。ActualPageServerReads/ActualPageServerReadAheads are added to query plan XML for actual plans. 次に例を示します。For example:

<RunTimeCountersPerThread Thread="8" ActualRows="90466461" ActualRowsRead="90466461" Batches="0" ActualEndOfScans="1" ActualExecutions="1" ActualExecutionMode="Row" ActualElapsedms="133645" ActualCPUms="85105" ActualScans="1" ActualLogicalReads="6032256" ActualPhysicalReads="0" ActualPageServerReads="0" ActualReadAheads="6027814" ActualPageServerReadAheads="5687297" ActualLobLogicalReads="0" ActualLobPhysicalReads="0" ActualLobPageServerReads="0" ActualLobReadAheads="0" ActualLobPageServerReadAheads="0" />

注意

クエリプランのプロパティウィンドウでこれらの属性を表示するには、SSMS 18.3 以降が必要です。To view these attributes in the query plan properties window, SSMS 18.3 or later is required.

仮想ファイルの統計と IO アカウンティングVirtual file stats and IO accounting

Azure SQL Database では、SQL Server IO を監視する主な方法は、sys.dm_io_virtual_file_stats() DMF です。In Azure SQL Database, the sys.dm_io_virtual_file_stats() DMF is the primary way to monitor SQL Server IO. Hyperscale の IO 特性は、その 分散アーキテクチャ によって異なります。IO characteristics in Hyperscale are different due to its distributed architecture. このセクションでは、この DMF で表示されるデータ ファイルへの IO (読み取りと書き込み) に焦点を当てます。In this section, we focus on IO (reads and writes) to data files as seen in this DMF. Hyperscale では、この DMF で表示される各データ ファイルは、1 つのリモート ページ サーバーに対応します。In Hyperscale, each data file visible in this DMF corresponds to a remote page server. ここで説明する RBPEX キャッシュは、コンピューティング レプリカ上でカバーされていないキャッシュである SSD ベースのローカル キャッシュです。The RBPEX cache mentioned here is a local SSD-based cache, that is a non-covering cache on the compute replica.

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

ローカル RBPEX キャッシュは、ローカル SSD ストレージの計算レプリカ上に存在します。Local RBPEX cache exists on the compute replica, on local SSD storage. そのため、このキャッシュの IO は、リモート ページ サーバーの IO より高速です。Thus, IO against this cache is faster than IO against remote page servers. 現在、Hyperscale データベースの sys.dm_io_virtual_file_stats() には、コンピューティング レプリカのローカル RBPEX キャッシュに対して実行された IO を報告する特別な行があります。Currently, sys.dm_io_virtual_file_stats() in a Hyperscale database has a special row reporting the IO against the local RBPEX cache on the compute replica. この行の database_idfile_id の両方の列の値は 0 です。This row has the value of 0 for both database_id and file_id columns. たとえば、次のクエリでは、データベースの起動以降の RBPEX 使用状況の統計が返されます。For example, the query below returns RBPEX usage statistics since database startup.

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

RBPEX で実行された読み取りと、他のすべてのデータ ファイルに対して行われた集約読み取りとの比率から、RBPEX キャッシュ ヒット率が得られます。A ratio of reads done on RBPEX to aggregated reads done on all other data files provides RBPEX cache hit ratio.

データ読み取りData reads

  • コンピューティング レプリカの SQL Server エンジンによって発行された読み取りは、ローカル RBPEX キャッシュまたはリモート ページ サーバーのいずれかによって、または複数ページを読み取る場合はこの 2 つの組み合わせによって処理されることがあります。When reads are issued by the SQL Server engine on a compute replica, they may be served either by the local RBPEX cache, or by remote page servers, or by a combination of the two if reading multiple pages.
  • コンピューティング レプリカが特定のファイル (file_id 1 など) から一部のページを読み取るとき、このデータがローカル RBPEX キャッシュにのみ存在する場合、この読み取りのすべての IO は file_id 0 (RBPEX) に対するものと見なされます。When the compute replica reads some pages from a specific file, for example file_id 1, if this data resides solely on the local RBPEX cache, all IO for this read is accounted against file_id 0 (RBPEX). そのデータの一部がローカル RBPEX キャッシュにあり、一部がリモート ページ サーバーにある場合、IO は、RBPEX から提供される部分については file_id 0 に対するものと見なされ、リモート ページ サーバーから提供される部分については file_id 1 に対するものと見なされます。If some part of that data is in the local RBPEX cache, and some part is on a remote page server, then IO is accounted towards file_id 0 for the part served from RBPEX, and the part served from the remote page server is accounted towards file_id 1.
  • コンピューティング レプリカがページ サーバーから特定の LSN でページを要求したときに、ページ サーバーが、要求された LSN に追いついていない場合、コンピューティング レプリカでの読み取りは、ページ サーバーが追いつくまで待機してから、そのページがコンピューティング レプリカに返されます。When a compute replica requests a page at a particular LSN from a page server, if the page server has not caught up to the LSN requested, the read on the compute replica will wait until the page server catches up before the page is returned to the compute replica. コンピューティング レプリカでのページ サーバーからの読み取りでは、その IO で待機している場合、PAGEIOLATCH_* の待機の種類が表示されます。For any read from a page server on the compute replica, you will see the PAGEIOLATCH_* wait type if it is waiting on that IO. Hyperscale では、この待機時間には、ページサーバー上の要求されたページを必要なLSNに追いつくための時間と、ページサーバーからコンピューティング レプリカにページを転送するために必要な時間の両方が含まれます。In Hyperscale, this wait time includes both the time to catch up the requested page on the page server to the LSN required, and the time needed to transfer the page from the page server to the compute replica.
  • 先読みなどの大規模な読み取りは、多くの場合、"スキャッター/ギャザー" 読み取りを使用して行われます。Large reads such as read-ahead are often done using "Scatter-Gather" Reads. これにより、一度に最大 4 MB のページを読み取ることができ、これは SQL Server エンジンでの 1 回の読み取りと見なされます。This allows reads of up to 4 MB of pages at a time, considered a single read in the SQL Server engine. ただし、読み取り中のデータが RBPEX に存在する場合、バッファー プールと RBPEX で常に 8 KB のページが使用されるため、これらの読み取りは複数の個別の 8 KB の読み取りと見なされます。However, when data being read is in RBPEX, these reads are accounted as multiple individual 8 KB reads, since the buffer pool and RBPEX always use 8 KB pages. その結果、RBPEX に対して表示される読み取り IO の数が、エンジンによって実行された実際の IO 数よりも大きくなる場合があります。As the result, the number of read IOs seen against RBPEX may be larger than the actual number of IOs performed by the engine.

データ書き込みData writes

  • プライマリ コンピューティング レプリカは、ページ サーバーに直接書き込みません。The primary compute replica does not write directly to page servers. 代わりに、ログ サービスからのログ レコードは、対応するページ サーバーで再生されます。Instead, log records from the Log service are replayed on corresponding page servers.
  • コンピューティング レプリカで発生する書き込みは、主にローカル RBPEX (file_id 0) に書き込まれます。Writes that happen on the compute replica are predominantly writes to the local RBPEX (file_id 0). 8 KB を超える論理ファイルの書き込み (つまり、ギャザー書込みを使用して実行されるもの) では、バッファー プールと RBPEX は常に 8 KB のページを使用するため、各書き込み操作は RBPEX への複数の 8 KB の個別書き込みに変換されます。For writes on logical files that are larger than 8 KB, in other words those done using Gather-write, each write operation is translated into multiple 8 KB individual writes to RBPEX since the buffer pool and RBPEX always use 8 KB pages. その結果、RBPEX に対して表示される書き込み IO の数が、エンジンによって実行された実際の IO 数よりも大きくなる場合があります。As the result, the number of write IOs seen against RBPEX may be larger than the actual number of IOs performed by the engine.
  • RBPEX 以外のファイル、またはページ サーバーに対応する file_id 0 以外のデータ ファイルにも、書き込み回数が表示されます。Non-RBPEX files, or data files other than file_id 0 that correspond to page servers, also show writes. Hyperscale サービス レベルでは、コンピューティング レプリカがページ サーバーに直接書き込むことはないため、これらの書き込みはシミュレートされます。In the Hyperscale service tier, these writes are simulated, because the compute replicas never write directly to page servers. 書き込み IOPS とスループットは、コンピューティング レプリカで発生すると見なされますが、file_id 0 以外のデータ ファイルの待機時間は、ページ サーバーの書き込みの実際の待機時間を反映しません。Write IOPS and throughput are accounted as they occur on the compute replica, but latency for data files other than file_id 0 does not reflect the actual latency of page server writes.

ログ書き込みLog writes

  • プライマリ コンピューティングでは、ログ書き込みは sys.dm_io_virtual_file_stats の file_id 2 に相当します。On the primary compute, a log write is accounted for in file_id 2 of sys.dm_io_virtual_file_stats. プライマリ コンピューティングでのログ書き込みは、ログ ランディング ゾーンへの書き込みです。A log write on primary compute is a write to the log Landing Zone.
  • ログ レコードは、セカンダリ レプリカにはコミット時に書き込まれません。Log records are not hardened on the secondary replica on a commit. Hyperscale では、ログは ログ サービスによってセカンダリ リモート レプリカに非同期的に適用されます。In Hyperscale, log is applied by the Log service to the secondary replicas asynchronously. セカンダリ レプリカではログの書き込みは実際には行われないため、セカンダリ レプリカでのログ IO のアカウンティングは、追跡のみを目的としています。Because log writes don't actually occur on secondary replicas, any accounting of Log IOs on the secondary replicas is for tracking purposes only.

リソース使用率の統計でのデータ IOData IO in resource utilization statistics

ハイパースケール以外のデータベースでは、データファイルに対する合計読み取り/書き込み IOPS は、リソース ガバナンス データの IOPS 制限を基準として、avg_data_io_percent 列の dm_db_resource_stats および sys.resource_stats ビューで報告されます。In a non-Hyperscale database, combined read and write IOPS against data files, relative to the resource governance data IOPS limit, are reported in sys.dm_db_resource_stats and sys.resource_stats views, in the avg_data_io_percent column. ポータルでは、同じ値が データ IO の割合 として報告されます。The same value is reported in the portal as Data IO Percentage.

Hyperscale データベースでは、この列は、データ IOPS の使用率を、コンピューティング レプリカのみのローカル ストレージの制限 (特に RBPEX および tempdb に対する IO) を基準として報告します。In a Hyperscale database, this column reports on data IOPS utilization relative to the limit for local storage on compute replica only, specifically IO against RBPEX and tempdb. この列の100% 値は、リソース ガバナンスがローカル ストレージの IOPS を制限していることを示します。A 100% value in this column indicates that resource governance is limiting local storage IOPS. これがパフォーマンスの問題に関連付けられている場合は、負荷の少ない IO を生成するようにワークロードを調整するか、データベースサービスの目標値を増やして、リソース ガバナンス 最大データ IOPS 制限 を増やします。If this is correlated with a performance problem, tune the workload to generate less IO, or increase database service objective to increase the resource governance Max Data IOPS limit. RBPEX の読み取りと書き込みのリソースガバナンスでは、システムは、SQL Server エンジンによって発行される可能性のある、より大きな IO ではなく、個々の 8 KB の IO をカウントします。For resource governance of RBPEX reads and writes, the system counts individual 8 KB IOs, rather than larger IOs that may be issued by the SQL Server engine.

リモートページサーバーに対するデータ IO は、リソース使用率ビューまたはポータルでは報告されませんが、前述のように、sys.dm_io_virtual_file_stats() DMF で報告されます。Data IO against remote page servers is not reported in resource utilization views or in the portal, but is reported in the sys.dm_io_virtual_file_stats() DMF, as noted earlier.

その他のリソースAdditional resources