次の方法で共有


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

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

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

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

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

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

トラブルシューティング ガイドを使用して、高い CPU 使用率のシナリオの考えられる根本原因を特定し、見つかった問題を軽減するための推奨事項を読むことができます。

トラブルシューティング ガイドを設定して使用する方法については、トラブルシューティング ガイドのセットアップに関する記事に従ってください。

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

高い CPU 使用率を特定するには、次の一覧に示すツールの使用を検討してください。

Azure メトリック

特定の期間の CPU 使用率を調べるには、Azure メトリックから始めることをお勧めします。 メトリックを見ると、CPU 使用率が高い期間中に使われていたリソースに関する情報がわかります。 書き込み IOPS読み取り IOPS読み取りスループット バイト/秒書き込みスループット バイト/秒のグラフを CPU 使用率と比べて、ワークロードが高い CPU の原因になっていたときを調べます。

プロアクティブな監視のために、メトリックに対してアラートを構成できます。 ステップバイステップ ガイダンスについては、「Azure メトリック」を参照してください。

クエリ ストア

クエリ ストアは、クエリと実行時統計の履歴を自動的にキャプチャし、ユーザーが確認できるようにそれを保持します。 時間でデータがスライスされるため、時間を追って使用パターンを確認できます。 すべてのユーザー、データベース、クエリに関するデータが Azure Database for PostgreSQL フレキシブル サーバー インスタンス内の azure_sys という名前のデータベースに保存されます。

クエリ ストアを使うと、待機イベント情報とクエリ実行時の統計情報を関連付けることができます。 クエリ ストアを使って、対象期間中に CPU を多く消費したクエリを特定します。

詳細については、クエリ ストアに関する記事を参照してください。

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 とメモリの使用率が高くなる可能性があります。

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

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

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

高い CPU 使用率を解決するには、EXPLAIN ANALYZE を使い、組み込みの PgBouncer 接続プーラーの使用を検討して、実行時間の長いトランザクションを終了します。

EXPLAIN ANALYZE を使用する

CPU の使用量が多いクエリがわかったら、EXPLAIN ANALYZE を使ってさらに調査し、それをチューニングします。

EXPLAIN ANALYZE コマンドの詳細については、ドキュメントを参照してください。

PgBouncer 組み込み接続プーラー

短時間の接続が多い場合や、有効期間のほとんどがアイドル状態のままである接続が多い場合は、PgBouncer などの接続プーラーの使用を検討します。

PgBouncer について詳しくは、接続プーラーに関する記事と、「PostgreSQL での接続処理のベスト プラクティス」をご覧ください。

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_autovacuumlast_autoanalyze列は、テーブルが最後に自動バキュームまたは分析された日時を示します。 テーブルが定期的にバキュームされていない場合は、自動バキュームを調整するステップを実行します。

自動バキュームのトラブルシューティングとチューニングの詳細については、「自動バキューム トラブルシューティング」を参照してください。

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

VACUUM ANALYZE <table>;