パフォーマンス シナリオを調べる

  • 5 分

パフォーマンス ツールと機能の使用方法を決定するには、シナリオを通じて Azure SQL のパフォーマンスを確認することが重要です。

一般的なパフォーマンス シナリオについて

SQL Server のパフォーマンストラブルシューティングの一般的な手法は、パフォーマンスの問題が 実行中 (CPU が高い) か 待機 中 (リソースで待機中) かを調べることです。 次の図は、SQL Server のパフォーマンスの問題が実行中または待機中のどちらであるかを特定するためのデシジョン ツリーと、パフォーマンス ツールを使用して原因と解決策を特定する方法を示しています。

実行中と待機中の図。

まず、リソースの全体的な使用状況を確認します。 標準の SQL Server デプロイの場合は、Windows のパフォーマンス モニターや Linux の top などのツールを使うこともできます。 Azure SQL では、次の方法を使用できます。

  • Azure portal、PowerShell、アラート

    Azure Monitor には、Azure SQL のリソース使用状況を表示するためのメトリックが統合されています。 また、リソース使用状況の状態を検出するためのアラートを設定することもできます。

  • sys.dm_db_resource_stats

    Azure SQL Database の場合は、この DMV を調べて、データベース デプロイの CPU、メモリ、I/O のリソース使用状況を確認できます。 この DMV は、このデータのスナップショットを 15 秒ごとに取得します。

  • sys.server_resource_stats

    この DMV は sys.dm_db_resource_stats と同様に動作しますが、SQL マネージド インスタンスの CPU、メモリ、I/O のリソース使用状況を確認するために使用されます。 この DMV もまた、スナップショットを 15 秒ごとに取得します。

  • sys.dm_user_db_resource_governance

    Azure SQL Database の場合は、この DMV によって、現在のデータベースまたはエラスティック プールのリソース ガバナンス メカニズムによって使用されている実際の構成と容量の設定が返されます。

  • sys.dm_instance_resource_governance

    Azure SQL Managed Instance の場合は、この DMV によって、sys.dm_user_db_resource_governance と同様の情報が、現在の SQL Managed Instance に対して返されます。

ランニング

問題が高い CPU 使用率であると特定した場合、これは実行中のシナリオと呼ばれます。 実行中のシナリオには、コンパイルや実行でリソースを消費するクエリが含まれる場合があります。 詳細な分析を行うには、次のツールを使用します。

  • クエリ ストア

    どのクエリがほとんどの CPU リソースを消費しているかを見つけるには、SSMS の [Top Consuming Resource] (上位のリソース消費) レポート、[クエリ ストア] カタログ ビュー、または Azure portal の Query Performance Insight (Azure SQL Database のみ) を使用します。

  • sys.dm_exec_requests

    アクティブなクエリの状態のスナップショットを取得するには、Azure SQL でこの DMV を使用します。 十分な CPU 容量があるかどうかを確認するには、状態が RUNNABLE で、待機の種類が SOS_SCHEDULER_YIELD であるクエリを探します。

  • sys.dm_exec_query_stats

    この DMV をクエリ ストアと同様に使用すると、上位のリソース消費クエリを見つけることができます。 キャッシュされたクエリ プランでのみ使用できます。一方、クエリ ストアではパフォーマンスの永続的な履歴レコードが提供されます。 この DMV ではまた、キャッシュされたクエリのクエリ プランを見つけることもできます。

  • sys.dm_exec_procedure_stats

    この DMV は、パフォーマンス情報をストアド プロシージャ レベルで表示できる点を除き、sys.dm_exec_query_stats と同様の情報を提供します。

    どのようなクエリが最も多くのリソースを消費しているかを特定したら、ワークロード用に十分な CPU リソースがあるかどうかを調べることが必要になる場合があります。 軽量クエリ プロファイリング、SET ステートメント、クエリ ストア、拡張イベント トレースなどのツールを使用してクエリ プランをデバッグできます。

待つこと

問題が高い CPU リソース使用率ではないと思われる場合は、リリソースの待機に関連するパフォーマンスの問題である可能性があります。 リソースの待機に関連するシナリオには次のものがあります。

  • I/O の待機
  • ロックの待機
  • ラッチの待機
  • バッファー プールの制限
  • メモリ許可
  • プラン キャッシュの削除

待機中のシナリオに対する分析を実行するには、通常、次のツールを調べます。

  • sys.dm_os_wait_stats

    データベースまたはインスタンスの上位の待機の種類を確認するには、この DMV を使用します。 これにより、上位の待機の種類に応じて、次に実行すべきアクションに関するガイドが提供されます。

  • sys.dm_exec_requests

    アクティブなクエリの特定の待機の種類を見つけて、どのようなリソースを待機しているかを確認するには、この DMV を使います。 これは、他のユーザーからのロックを待機している標準的なブロックのシナリオである可能性があります。

  • sys.dm_os_waiting_tasks

    この DMV を使用すると、現在実行中の特定のクエリの特定のタスクの待機の種類を見つけることができます。通常よりも時間がかかっている理由を確認できます。 sys.dm_os_waiting_tasks には、sys.dm_os_wait_stats が時間の経過と共に集計したライブ待機統計が含まれます。

  • クエリ ストア

    クエリ ストアは、クエリ プラン実行の上位の待機の集計を示すレポートとカタログ ビューを提供します。 CPU の待機は実行中の問題と同等であることを知る必要があります。

Azure SQL に固有のシナリオ

Azure SQL に固有のいくつかのパフォーマンス シナリオ (実行中と待機中の両方) があります。 これには、ログ ガバナンス、ワーカーの制限、Business Critical サービス レベルで発生した待機、Hyperscale デプロイに固有の待機が含まれます。

ログ ガバナンス

Azure SQL では、ログ レート ガバナンスを使用して、トランザクション ログの使用に関するリソース制限を適用できます。 この適用は、リソース制限を確保し、約束された SLA を満たすために必要になります。 ログ ガバナンスは、次の待機の種類から確認できます。

  • LOG_RATE_GOVERNOR: Azure SQL Database を待機します
  • POOL_LOG_RATE_GOVERNOR: エラスティック プールを待機します
  • INSTANCE_LOG_GOVERNOR: Azure SQL Managed Instance を待機します
  • HADR_THROTTLE_LOG_RATE*: Business Critical と geo レプリケーションの待機時間を待機します

ワーカーの制限

SQL Server はスレッドのワーカー プールを使用しますが、ワーカーの最大数に関する制限があります。 同時ユーザー数が多いアプリケーションは、Azure SQL Database と SQL Managed Instance に適用されているワーカー制限に近づく可能性があります。

  • Azure SQL Database には、サービス レベルとサイズに基づいた制限があります。 この制限を超えた場合は、新しいクエリにエラーが返されます。
  • 現時点で、SQL Managed Instance は max worker threads を使っているため、この制限を超えたワーカーには THREADPOOL 待機が表示される可能性があります。

Business Critical HADR 待機

Business Critical サービス レベルを使用している場合は、次の待機の種類が予期せず表示されることがあります。

  • HADR_SYNC_COMMIT
  • HADR_DATABASE_FLOW_CONTROL
  • HADR_THROTTLE_LOG_RATE_SEND_RECV

これらの待機によりアプリケーションの速度は低下しないかもしれませんが、あなたはこれらの表示を予期していない可能性があります。 通常、これらは Always On 可用性グループの使用に固有のものです。 Business Critical レベルでは、可用性グループ テクノロジを使用して Business Critical サービス レベルの SLA と可用性機能を実装するため、これらの待機の種類が予測されます。 長い待機時間は、I/O 待機時間やレプリカビハインドなどのボトルネックを示している可能性があります。

Hyperscale

Hyperscale アーキテクチャでは、一部の一意の待機の種類の前に RBIO が付く場合があります (ログ ガバナンスを示す可能性があります)。 さらに、DMV、カタログ ビュー、および拡張イベントが強化され、ページ サーバーの読み取りのメトリックが表示されます。

次の演習では、このユニットで取得したツールと知識を使って、Azure SQL のパフォーマンスの問題を監視して解決する方法について説明します。