高い CPU 使用率または CPU 使用率の急上昇は、クエリのパフォーマンスに影響を与え、応答を遅くする可能性があります。このトピックでは、CPU 使用率を表示する方法と、ApsaraDB RDS for SQL Server インスタンスの高い CPU 使用率の原因となる問題のトラブルシューティング方法について説明します。
CPU 使用率の表示
ApsaraDB RDS コンソールで RDS インスタンスの CPU 使用率を表示できます。
共有インスタンスファミリーは、CPU リソースの再利用をサポートしています。共有インスタンスファミリーを選択すると、インスタンスの CPU 使用率が高くない場合でも、CPU リソースの再利用が原因で、RDS インスタンスのパフォーマンスが制限される可能性があります。安定した高パフォーマンスが必要な場合は、専用インスタンスファミリーを選択することをお勧めします。
RDS インスタンスがリソースが少ないインスタンスタイプを使用しているにもかかわらず、高い同時実行性が発生する場合、CPU リソースが枯渇する可能性もあります。安定した高パフォーマンスが必要な場合は、インスタンスタイプをアップグレードすることをお勧めします。
方法 1：監視とアラートページで CPU 使用率を表示する
RDS インスタンスのモニターとアラーム ページに移動します。[標準モニタリング] タブで、RDS インスタンスの CPU 使用率を表示します。
方法 2：自律サービスページで CPU 使用率を表示する
RDS インスタンスはクラウドディスクで SQL Server 2008 R2 を実行していません。
RDS インスタンスは、次のいずれかのリージョンにあります。中国 (杭州)、中国 (上海)、中国 (青島)、中国 (北京)、中国 (張家口)、中国 (フフホト)、中国 (ウランチャブ)、中国 (深圳)、中国 (河源)、中国 (広州)、中国 (成都)、中国 (香港)、シンガポール、UAE (ドバイ)
インスタンスの詳細ページの左側のナビゲーションウィンドウで、自律型サービス (CloudDBA)性能を最適化する を選択します。表示されるページのパフォーマンスインサイト タブで、RDS インスタンスの CPU 使用率を表示します。
CPU メトリックの分析
原因
ほとんどの場合、CPU 使用率の急激な増加は、次の問題が原因で発生します。
クエリリクエストの数が急激に増加する。たとえば、ワークロードが急激に増加したり、データキャッシュレイヤーでキャッシュペネトレーションが発生したりします。
クエリリクエストの CPU オーバーヘッドが急激に増加する。たとえば、新しいクエリリクエストが非効率的な方法で処理されたり、一部のクエリ文の実行プランが変更されたりします。
システムがクエリ文の実行プランをコンパイルする頻度が大幅に増加する。たとえば、大量のデータをキャッシュする必要がある場合、キャッシュされる実行プランの数とキャッシュヒット率が大幅に低下します。この場合、既存の実行プランを再利用できず、システムは SQL 文の実行プランを頻繁にコンパイルする必要があります。その結果、RDS インスタンス全体の CPU オーバーヘッドが大幅に増加します。
ほとんどのワークロードで使用されるキャッシュされた実行プランが最適ではないために、パラメータスニッフィングの問題が発生する。
問題分析
インスタンスの詳細ページの左側のナビゲーションウィンドウで、自律型サービス (CloudDBA)性能を最適化する を選択します。表示されるページのパフォーマンスインサイト タブで、次のメトリックを表示して、RDS インスタンスの CPU 使用率の増加の原因を特定します。
タブには最大 8 種類のメトリックを表示できます。タブで次のメトリックが見つからない場合は、パフォーマンスインサイト タブの右上隅にある[カスタムメトリック] をクリックできます。表示されるダイアログボックスで、タブに表示するメトリックを選択できます。
メトリック | 分析 | |
QPS | QPS メトリックの値が CPU 使用率と同じ割合で増加する場合、CPU 使用率の増加はクエリリクエスト数の増加が原因です。これは、CPU 使用率の増加が RDS インスタンスに起因するものではないことを示しています。 CPU 使用率の増加をトラブルシューティングするには、アプリケーションを分析する必要があります。 |
|
Page_Lookups/sec | Page_Lookups/sec メトリックは、クエリリクエストを処理するために論理的に読み取られる 1 秒あたりのページの累積数を示します。ほとんどの場合、Page_Lookups/sec メトリックの値は、システムが非効率的な方法でクエリ文を実行するために増加します。このメトリックの値が高い場合、クエリリクエストの CPU オーバーヘッドが高くなります。Page_Lookups/sec メトリックの値が CPU 使用率と同じ割合で増加する一方で、QPS メトリックの値が比較的安定している場合、クエリ文の CPU オーバーヘッドが増加します。この場合、CPU 使用率の増加の原因となっているクエリ文の種類を特定する必要があります。次に、これらのタイプのクエリ文を最適化して、CPU 使用率を削減できます。 |
|
Sqlcompliations | Sqlcompliations メトリックは、クエリリクエストの 1 秒あたりのコンパイル操作の数を示します。Sqlcompliations メトリックの値が CPU 使用率と同じ割合で増加する一方で、QPS メトリックの値が比較的安定している場合、CPU 使用率の増加は、クエリリクエストの実行プランをコンパイルするために必要な CPU オーバーヘッドが原因である可能性があります。キャッシュされた実行プランの数に関連するCache_Object_Counts メトリックとCache_Pages メトリックをさらに確認できます。これらのメトリックの値が大幅に減少した場合、CPU 使用率の増加は、キャッシュへの非常に高い負荷が原因である可能性があります。このような場合、効果的な解決策は、インスタンスの仕様を変更して RDS インスタンスのメモリ容量を増やすことです。詳細については、「インスタンス仕様の変更」および「プライマリ ApsaraDB RDS for SQL Server インスタンスのインスタンスタイプ」をご参照ください。 |
|
例
次の図は、サンプルケースを示しています。
CPU 使用率の統計によると、CPU 使用率の増加は 09:10 から 09:20 と 09:30 から 09:40 に発生しています。ただし、QPS メトリックの値は、これらの期間中は増加しません。QPS メトリックの値は 09:40 後に増加します。したがって、CPU 使用率の増加は、クエリリクエスト数の増加が原因ではありません。
Sqlcompliations メトリックの値は、これらの期間中は増加せず、このメトリックの絶対値は低いです。したがって、CPU 使用率の増加は、クエリ文の実行プランをコンパイルするために必要な CPU オーバーヘッドが原因ではありません。
Page_Lookups/sec メトリックの値は、これらの期間中に CPU 使用率と同じ割合で増加します。したがって、CPU 使用率の増加は、これらの期間中に一部のクエリリクエストの処理に必要な高い CPU オーバーヘッドが原因である可能性があります。
これらの期間中に高い CPU オーバーヘッドを必要とするクエリ文を特定する必要があります。Page_Lookups/sec メトリックの値が増加すると、CPU 使用率も増加します。一部のクエリ文は、実行には高い CPU オーバーヘッドが必要ですが、論理読み取り操作には中程度の CPU オーバーヘッドが必要です。したがって、CPU 使用率の増加をトラブルシューティングするには、これらの期間中に実行されるクエリ文を分析する必要があります
アクティブセッションの分析
原因
CPU 使用率の急激な増加の最も一般的な原因は、クエリ文を実行するために使用される方法の非効率性です。 パフォーマンスインサイト の平均アクティブセッション (AAS) メトリックを使用して、非効率的な方法で実行されるクエリ文を特定して分析できます。
問題分析
システムは 10 秒ごとにアクティブセッションをチェックし、アクティブなクエリリクエストの SQL 文、クエリハッシュ値、実行プラン、および待機イベントを記録します。ほとんどの場合、高い CPU オーバーヘッドを必要とするクエリ文が実行されている場合、[待機] タブのクエリ文の [待機カテゴリ] 列の値は CPU です。
[SQL] タブの[SQL ハッシュ] 列には、SQL 文がパラメーターに基づいて構造化された後に生成されるハッシュ値が表示されます。ハッシュ値は、同じ構造を使用する SQL 文をマークして集約するために使用されます。このようにして、システムは SQL 文の構造に基づいて SQL 文を分類して集約できます。 sys.dm_exec_query_stats システムビューから、SQL 文のQuery_hash 列の値に基づいて、SQL 文の最新の統計をクエリできます。
識別
[SQL] タブの[SQL ハッシュ] 列のハイパーリンクをクリックして、SQL 文の AAS 統計を表示します。
[SQL] タブの[実行プラン] 列の[分析] をクリックして、SQL 文の実行プランを表示します。自律サービスによって生成された最適化の提案も表示できます。
上記の最適化の提案は、構造が単純な SQL 文に適しています。 RDS インスタンスの SQL 文の構造が複雑な場合は、上記の最適化の提案に基づいて、これらの SQL 文の実行プランをさらに分析およびテストすることをお勧めします。 AAS メトリックの詳細については、「パフォーマンスインサイト機能の使用」をご参照ください。
上位 N 個の SQL 文の分析
原因
自律サービスの ASS メトリックを使用して、特定の期間中に CPU 使用率の増加の原因となっている SQL 文を特定できます。ただし、さまざまな SQL 文の実行頻度、平均 CPU オーバーヘッド、全体的な CPU オーバーヘッドなどの情報は提供されません。 RDS インスタンス全体の CPU 使用率を最適化する場合、最も多くの CPU リソースを消費する SQL 文に関する詳細を取得することをお勧めします。
問題分析
SQL Server は、SQL 文やストアドプロシージャなどのオブジェクトに関する情報を自動的に集約できます。また、SQL Server は、sys.dm_exec_query_stats やsys.dm_exec_procedure_stats などのシステムビューを提供して、オブジェクトに関する情報を表示できるようにします。次に、最も多くのリソースを消費する SQL 文を特定できます。リソースはさまざまなタイプのものがあります。
自律サービスの TOP SQL レポートと TOP オブジェクトレポート、および SQL Server Management Studio (SSMS) の上位 N 個のクエリレポートも、システムビューに基づいています。これらのレポートは使いやすくなっていますが、システムビューほど柔軟ではありません。
パラメーター設定の最適化
最大並列度 (MAXDOP) は、単一のクエリリクエストで同時に使用できるスレッドの最大数を制限するために使用されます。本質的に、複数プロセッサが連携して複雑なクエリを高速化します。 CPU 集中型のクエリの場合、高い並列度 (DOP) は実行期間を短縮できますが、より多くのシステムスケジューリングリソースを消費し、競合を引き起こす可能性があります。パラメーターを構成する場合は、クエリの応答時間と全体的なスループットを考慮する必要があります。次の説明に基づいてパラメーターを構成することをお勧めします。
高同時実行性シナリオ
シナリオには、オンライントランザクション処理 (OLTP) システムが含まれます。システムが多数の同時リクエストを処理する必要があり、ほとんどのクエリの実行時間が 5 秒未満の場合、
MAXDOP≤4設定を使用することをお勧めします。高頻度のインデックス操作またはパーティションテーブルスキャンが存在する場合は、MAXDOP=1設定を使用して、並列実行プランのオーバーヘッドを防ぐことができます。低同時実行性シナリオ
シナリオには、オンライン分析処理 (OLAP) システムとレポートシステムが含まれます。ビッグデータの集計やスター結合など、単一の複雑なクエリの DOP を増やすことができます。次の式を使用して計算された値に DOP を増やすことをお勧めします。
MAXDOP=min[(論理 CPU コア数/同時クエリ数),8]。パラメーターの最大値は、論理 CPU コア数の 75% を超えることはできません。たとえば、64 個の CPU コアを持つシステムの場合、パラメーターを 48 以上の値に設定できます。
MAXDOP パラメーターのデフォルト値は 2 であり、同時実行性とリソースの競合のリスクを軽減します。EXECUTE sp_rds_configure 'max degree of parallelism', <value> 文を実行して、パラメーターを動的に変更できます。パラメーターを変更した後、CXPACKET 待機タイプを指定する CXPACKET メトリックと、SQL Server スケジューラがタスクの処理に使用する時間の割合を指定するScheduler Busy% メトリックを必ず監視してください。デフォルト値が 5 であるcost threshold for parallelism も変更することをお勧めします。
参照
ApsaraDB RDS for SQL Server インスタンスの CPU 使用率が高い場合はどうすればよいですか?