CPU - Amazon Aurora
サポート対象エンジンバージョンContext待機時間が増加する原因の可能性アクション

CPU

この待機イベントは、スレッドが CPU でアクティブであるか CPU の待機中に発生します。

サポート対象エンジンバージョン

この待機イベント情報は、Aurora PostgreSQL バージョン 9.6 以降に関連します。

Context

中央処理装置 (CPU)は、命令を実行するコンピュータのコンポーネントです。例えば、CPU 命令は演算処理を実行し、メモリ上でデータを交換します。クエリがデータベースエンジンを介して実行する命令の数が増えると、クエリの実行にかかる時間が長くなります。CPU スケジューリングは、CPU にプロセス時間を与えています。スケジューリングは、OS のカーネルによってオーケストレーションされます。

この待機の発生時期を確認する方法

このCPU待機イベントは、バックエンドプロセスが CPU でアクティブであるか、CPU を待っていることを示します。クエリに次の情報が表示されると、発生していることがわかります。

  • 「pg_stat_activity.state」 列には値activeがあります。

  • pg_stat_activityのwait_event_typeおよびwait_eventの列は、両方ともnullです。

CPU を使用中または待機中のバックエンドプロセスを確認するには、次のクエリを実行します。

SELECT * 
FROM   pg_stat_activity
WHERE  state = 'active'
AND    wait_event_type IS NULL
AND    wait_event IS NULL;

DbLoadCPU メトリクス

CPU の Performance Insights のメトリクスは DBLoadCPU です。DBLoadCPUの値は、Amazon CloudWatch メトリクスの値とは異なる場合がありますCPUUtilization。後者のメトリクスは、データベースインスタンスのハイパーバイザーから収集されます。

os.cpuUtilization メトリック

Performance Insights OS のメトリクスは、CPU 使用率に関する詳細情報を提供します。例えば、次のメトリクスを表示できます。

  • os.cpuUtilization.nice.avg

  • os.cpuUtilization.total.avg

  • os.cpuUtilization.wait.avg

  • os.cpuUtilization.idle.avg

Performance Insights は、データベースエンジンによる CPU 使用率をos.cpuUtilization.nice.avgのように報告します。

CPU スケジューリングの原因の可能性

OS の観点から、CPU はアイドルスレッドを実行していないときはアクティブです。CPU は計算の実行中はアクティブですが、メモリ I/O の待機中もアクティブになります。このタイプの I/O は、一般的なデータベースワークロードを支配します。

以下の条件が満たされると、プロセスは CPU でスケジュールされるのを待機する可能性があります。

  • CloudWatchCPUUtilizationメトリクスは 100% に近いです。

  • 平均ロードは vCPUs の数よりも大きく、ロードが重いことを示しています。このメトリクスは、loadAverageMinutePerformance Insights の OS メトリクスセクションで見ることができます。

待機時間が増加する原因の可能性

CPU 待機イベントが通常よりも頻繁に発生する場合は、パフォーマンスの問題を示している可能性があり、典型的な原因は次のとおりです。

突然のスパイクの原因の可能性

突然のスパイクの原因として最も可能性の高いものは次のとおりです。

  • アプリケーションがデータベースへの同時接続を開きすぎています。このシナリオは「接続ストーム」と呼ばれます。

  • アプリケーションのワークロードは、次のいずれかの方法で変更されました。

    • 新しいクエリ

    • データセットのサイズの増加

    • インデックスのメンテナンスまたは作成

    • 新しい関数

    • 新しいオペレーター

    • パラレルクエリ実行の増加

  • クエリ実行プランが変更されました。場合によっては、変更によってバッファが増加することがあります。例えば、以前はインデックスを使用していたクエリが、現在はシーケンシャルスキャンを使用します。この場合、同じ目標を達成するには、クエリがより多くの CPU を必要とします。

長期の高周波の原因の可能性

長期間にわたって再発するイベントの原因として最も可能性の高いもの:

  • CPU で同時に実行されているバックエンドプロセスが多すぎます。これらのプロセスは、パラレルワーカーにすることができます。

  • クエリのパフォーマンスは、大量のバッファを必要とするため最適ではありません。

コーナーケース

考えられる原因のいずれも実際の原因ではない場合は、以下のような状況が発生することがあります。

  • CPU がプロセスを入れ替えています。

  • CPU コンテキストスイッチングが増加しました。

  • Aurora PostgreSQL コードに待機イベントがありません。

アクション

CPU 待機イベントがデータベースアクティビティを占領している場合でも、必ずしもパフォーマンスの問題を示すわけではありません。パフォーマンスが低下した場合にのみ、このイベントに応答します。

データベースが CPU の増加原因かどうかを調べる

os.cpuUtilization.nice.avgPerformance Insights のメトリクスを検証します。この値が CPU 使用率よりはるかに小さい場合、データベース以外のプロセスが CPU の主な原因となっています。

接続数が増加したかどうかを判断する

DatabaseConnectionsAmazon CloudWatch のメトリクスを検証します。アクションは、CPU の待機イベントが増加した期間中の数値の増減によって異なります。

接続数が増加した

接続数が増えた場合は、CPU を消費しているバックエンドプロセスの数と vCPUs の数を比較します。以下のシナリオが考えられます。

  • CPU を消費するバックエンドプロセスの数が、vCPUs の数より少なくなっています。

    この場合、接続数は問題ではありません。ただし、それでも CPU 使用率を下げようとすることがあります。

  • CPU を消費するバックエンドプロセスの数が vCPUs の数を超えています。

    このような場合は、以下のオプションを検討します。

    • データベースに接続されているバックエンドプロセスの数を減らします。例えば、RDS Proxy などの接続プーリングソリューションを実装します。詳細については、「Amazon RDS Proxy for Aurora の使用」を参照してください。

    • インスタンスサイズをアップグレードして vCPUs の数を増やします。

    • 一部の読み取り専用ワークロードをリーダーノードにリダイレクトします (該当する場合)。

接続は増加しなかった

blks_hitPerformance Insights のメトリクスを検証します。blks_hitと CPU 使用率の増加の相関関係を探してください。以下のシナリオが考えられます。

  • CPU 使用率とblks_hitが相関しています。

    この場合、CPU 使用率にリンクされている上位 SQL ステートメントを検索し、プランの変更を検討します。以下のいずれかの対策を使用できます。

    • 計画をマニュアルで説明し、予想される実行プランと比較します。

    • 秒単位のブロックヒット数とローカルブロックヒット数の増加を確認します。Performance Insights ダッシュボードの上位 SQLセクションで、Preferences (設定) を選択します。

  • CPU 使用率とblks_hitには相関関係がありません。

    このような場合は、次のいずれかに該当するかどうかを判断します。

    • アプリケーションは、データベースとの接続と切断を高速で行っています。

      log_connectionsおよびlog_disconnectionsをオンにして、PostgreSQL のログを分析します。pgbadgerログアナライザの使用を検討します。詳細については、「https://github.com/darold/pgbadger」を参照してください。

    • OS はオーバーロード状態です。

      この場合、Performance Insights は、バックエンドプロセスが通常よりも長い時間 CPU を消費していることを示しています。Performance Insights のos.cpuUtilizationメトリクスサイトまたはCPUUtilizationCloudWatch のメトリクスでエビデンスを探します。OS がオーバーロード状態になっている場合は、拡張モニタリングのメトリックを参照してさらに診断します。具体的には、プロセスリストと各プロセスが消費する CPU の割合を確認します。

    • 上位 SQL ステートメントが消費する CPU が多すぎます。

      CPU 使用率とリンクするステートメントを検証し、CPU の使用率を減らせるかどうかを確認します。EXPLAINコマンドを実行し、最も影響が大きいプランノードにフォーカスします。PostgreSQL の実行計画ビジュアライザーの使用を検討してください。このツールを試すには、http://explain.dalibo.com/を参照してください。

ワークロードの変更に対応

ワークロードが変更された場合は、次のタイプの変更を探します。

新しいクエリ

新しいクエリが想定されているかどうかを確認します。その場合は、その実行計画と秒単位の実行数が想定されていることを確認してください。

データセットのサイズの増加

パーティショニングが未実装の場合は、それが役立つかどうかを判断します。この戦略では、クエリで取得する必要があるページ数を減らすことができます。

インデックスのメンテナンスまたは作成

メンテナンスのスケジュールが想定されているかどうかを確認します。ベストプラクティスは、ピークアクティビティ以外のメンテナンスアクティビティをスケジュールすることです。

新しい関数

これらの機能がテスト中に想定したとおりに動作するかどうかを確認します。具体的には、秒単位の実行数が想定されているかどうかを確認します。

新しいオペレーター

テスト中に想定どおりに動作するかどうかを確認します。

パラレルクエリの実行の増加

以下のいずれかの状況が発生するかどうかを確認します。

  • 関連する関係やインデックスのサイズが突然大きくなり、min_parallel_table_scan_sizeまたはmin_parallel_index_scan_sizeは大きく異なるようになりました。

  • 「parallel_setup_costまたはparallel_tuple_cost」に最近変更が加えられました。

  • 「max_parallel_workersまたはmax_parallel_workers_per_gather」に最近変更が加えられました。