次の方法で共有

Azure Database for PostgreSQL の CPU 使用率が高い場合のトラブルシューティング - フレキシブル サーバー

  • [アーティクル]

適用対象: Azure Database for PostgreSQL - フレキシブル サーバー

この記事では、CPU 使用率が高い根本原因を迅速に特定する方法と、Azure Database for PostgreSQL フレキシブル サーバーを使用する際に考えられる CPU 使用率を制御する修復アクションを示します。

この記事では、次の内容について説明します。

  • 根本原因を軽減するための推奨事項を特定して取得するためのトラブルシューティング ガイドについて。
  • Azure メトリック、クエリ ストア、pg_stat_statements など、高い CPU 使用率を識別するためのツールについて説明します。
  • 実行時間の長いクエリや合計接続数など、根本原因を特定する方法。
  • Explain Analyze、Connection Pooling、Vacuuming テーブルを使用して高い CPU 使用率を解決する方法。

トラブルシューティング ガイド

Azure Database for PostgreSQL フレキシブル サーバー ポータルで利用できる機能のトラブルシューティング ガイドを使用すると、高い CPU 使用率に関して考えられる根本原因と、その軽減シナリオに関する推奨事項を確認できます。 トラブルシューティング ガイドをセットアップして使用する方法については、トラブルシューティング ガイドのセットアップに従ってください。

高い CPU 使用率を識別するためのツール

高い CPU 使用率を確認するために、以下のツールを検討してください。

Azure メトリック

Azure メトリックは、明確な日付と期間の CPU 使用率を確認するための適切な開始点です。 メトリックは、CPU 使用率が高い期間に関する情報を提供します。 書き込み IOPS、読み取り IOPS、読み取りスループット、書き込みスループットのグラフを CPU 使用率と比較して、ワークロードで CPU が高い原因となった時間を確認します。 プロアクティブな監視のために、メトリックに対してアラートを構成できます。 ステップバイステップ ガイダンスについては、「Azure メトリック」を参照してください。

クエリ ストア

クエリ データ ストアでは、クエリおよびランタイム統計の履歴が自動的にキャプチャされて保持されるので、それらを確認できます。 時間別にデータがスライスされるため、一時的な使用パターンを確認できます。 すべてのユーザー、データベース、クエリに関するデータが Azure Database for PostgreSQL フレキシブル サーバー インスタンス内の azure_sys という名前のデータベースに保存されます。 ステップバイステップ ガイダンスについては、「クエリ データ ストア」をご覧ください。

pg_stat_statements

pg_stat_statements拡張機能は、サーバーで時間を消費するクエリを識別するのに役立ちます。

中間または平均実行時間

Postgres バージョン 13 以降では、次のステートメントを使用して、中間または平均実行時間で上位 5 つの SQL ステートメントを表示します。

SELECT userid::regrole, dbid, query, mean_exec_time
FROM pg_stat_statements
ORDER BY mean_exec_time
DESC LIMIT 5;

[総実行時間]

次のステートメントを実行して、合計実行時間別に上位 5 つの SQL ステートメントを表示します。

Postgres バージョン 13 以降では、次のステートメントを使用して、総実行時間で上位 5 つの SQL ステートメントを表示します。

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY total_exec_time
DESC LIMIT 5;

根本原因を特定する

CPU 消費レベルが概して高い場合は、次の原因が考えられます。

長時間トランザクション

実行時間の長いトランザクションは、CPU 使用率が高くなる可能性のある CPU リソースを消費する可能性があります。

次のクエリは、最長で実行されている接続を識別するのに役立ちます。

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

状態別の接続数と接続数の合計数

データベースへの接続の数が多いことも、CPU とメモリ使用率の増加につながる可能性のあるもう 1 つの問題です。

次のクエリは、状態別の接続数に関する情報を提供します。

SELECT state, count(*)
FROM  pg_stat_activity
WHERE pid <> pg_backend_pid()
GROUP BY 1 ORDER BY 1;

CPU の使用率の高さを解決する

Explain Analyze、PG Bouncer、接続プールを使用し、実行時間の長いトランザクションを終了して、高い CPU 使用率を解決します。

Explain Analyze を使用する

長時間実行されているクエリがわかったら、 EXPLAIN を使用してクエリをさらに調査し、調整します。
EXPLAIN コマンドの詳細については、「プランの説明」を参照してください。

PGBouncer と接続プール

アイドル状態の接続が多い場合や、CPU を消費している接続の数が多い場合は、PgBouncer のような接続プーラーの使用を検討してください。

PgBouncer の詳細については、以下を参照してください。

接続プーラー

ベスト プラクティス

Azure Database for PostgreSQL フレキシブル サーバーでは、組み込みの接続プール ソリューションとして PgBouncer が提供されます。 詳細については、「PgBouncer」を参照してください

実行時間の長いトランザクションを終了する

実行時間の長いトランザクションをオプションとして強制終了することを検討できます。

セッションの PID を終了するには、次のクエリを使用して PID を検出する必要があります。

SELECT pid, usename, datname, query, now() - xact_start as duration
FROM pg_stat_activity
WHERE pid <> pg_backend_pid() and state IN ('idle in transaction', 'active')
ORDER BY duration DESC;

usename(ユーザー名)、datname(データベース名) などの他のプロパティでフィルター処理することもできます。

セッションの PID を取得したら、次のクエリを使用して終了できます。

SELECT pg_terminate_backend(pid);

バキュームとテーブルの統計を監視する

テーブルの統計情報を最新の状態に保つことは、クエリのパフォーマンスを向上させるのに役立ちます。 通常の自動バキュームが実行されているかどうかを監視します。

次のクエリは、バキュームが必要なテーブルを特定するのに役立ちます。

select schemaname,relname,n_dead_tup,n_live_tup,last_vacuum,last_analyze,last_autovacuum,last_autoanalyze
from pg_stat_all_tables where n_live_tup > 0;

last_autovacuumと last_autoanalyze列は、テーブルが最後に自動バキュームまたは分析された日時を示します。 テーブルが定期的にバキュームされていない場合は、自動バキュームを調整するステップを実行します。 自動バキュームのトラブルシューティングとチューニングの詳細については、「自動バキューム トラブルシューティング」を参照してください。

短期的な解決策は、低速クエリが表示されるテーブルを手動でバキューム分析することです。

vacuum analyze <table_name>;

関連するコンテンツ