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

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

この記事では、IOPS (1 秒あたりの入出力操作) 使用率が高い根本原因を迅速に特定する方法を示し、Azure Database for PostgreSQL フレキシブル サーバーを使用する場合に、IOPS 使用率を制御する修復アクションを提供します。

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

• 根本原因を軽減するための推奨事項を特定して取得するためのトラブルシューティング ガイドについて。
• Azure メトリック、クエリ ストア、pg_stat_statements など、高い入出力 (I/O) 使用率を識別するためのツールを使用します。
• 実行時間の長いクエリ、チェックポイントのタイミング、中断を伴う自動バキューム デーモン プロセス、高いストレージ使用率など、根本原因を特定します。
• Explain Analyze を使用して高い I/O 使用率を解決し、チェックポイント関連のサーバー パラメーターを調整し、自動バキューム デーモンを調整します。

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

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

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

高い I/O 使用率を特定するには、次のツールを検討してください。

Azure メトリック

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

クエリ ストア

クエリ ストア機能では、クエリおよびランタイム統計の履歴が自動的にキャプチャされ、確認のために保持されます。 時間別にデータがスライスされ、一時的な使用パターンが表示されます。 すべてのユーザー、データベース、クエリに関するデータが Azure Database for PostgreSQL フレキシブル サーバー インスタンス内の azure_sys という名前のデータベースに保存されます。 手順を追ったガイダンスについては、「クエリ ストアによるパフォーマンスの監視」を参照してください。

I/O を消費する上位 5 つの SQL ステートメントを表示するには、次のステートメントを使用します。

select * from query_store.qs_view qv where is_system_query is FALSE
order by blk_read_time + blk_write_time  desc limit 5;

pg_stat_statements 拡張機能

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

I/O を消費する上位 5 つの SQL ステートメントを表示するには、次のステートメントを使用します。

SELECT userid::regrole, dbid, query
FROM pg_stat_statements
ORDER BY blk_read_time + blk_write_time desc
LIMIT 5;

根本原因を特定する

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

長時間トランザクション

実行時間の長いトランザクションでは I/O を消費する場合があるため、I/O 使用率が高くなる可能性があります。

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

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;

チェックポイントのタイミング

高い I/O は、チェックポイントの発生頻度が高すぎるシナリオで見られることもあります。 これを識別する 1 つの方法は、Azure Database for PostgreSQL フレキシブル サーバーのログ ファイルで "ログ: チェックポイントが頻繁に発生しています" という内容のログ テキストを確認することです。

pg_stat_bgwriter の定期的なスナップショットがタイムスタンプ付きで保存される方法を使用して、調査することもできます。 保存したスナップショットを使用して、平均チェックポイント間隔、要求されたチェックポイントの数、時間指定のチェックポイントの数を計算できます。

中断を伴う自動バキューム デーモン プロセス

自動バキュームを監視するには、次のクエリを実行します。

SELECT schemaname, relname, n_dead_tup, n_live_tup, autovacuum_count, last_vacuum, last_autovacuum, last_autoanalyze, autovacuum_count, autoanalyze_count FROM pg_stat_all_tables WHERE n_live_tup > 0;

このクエリは、データベース内のテーブルがバキュームされる頻度を確認するために使用されます。

• last_autovacuum: テーブルで最後の自動バキュームが実行された日時。
• autovacuum_count: テーブルがバキュームされた回数。
• autoanalyze_count: テーブルが分析された回数。

高い I/O 使用率を解決する

高い I/O 使用率を解決するには、次の 3 つの方法のいずれかを使用できます。

EXPLAIN ANALYZE コマンド

IO 使用量が多いクエリを特定したら、EXPLAIN ANALYZE を使用してそのクエリをさらに調査し、調整を加えます。 EXPLAIN ANALYZE コマンドの詳細については、EXPLAIN プランに関する記事を参照してください。

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

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

セッションのプロセス ID (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);

サーバー パラメーターを調整する

チェックポイントの発生頻度が高すぎることが確認された場合は、ほとんどのチェックポイントが要求ベースではなく時間駆動になるまで、サーバー パラメーター max_wal_size を増やします。 最終的には、90% 以上を時間ベースにする必要があり、2 つのチェックポイント間の間隔は、サーバーに設定された checkpoint_timeout 値に近くする必要があります。

• max_wal_size: ピークの営業時間は、max_wal_size 値に到達するちょうど良いタイミングです。 値に達するためには、次の操作を行います。

  1. 次のクエリを実行して現在の WAL LSN を取得し、結果をメモします。

     select pg_current_wal_lsn();
     

  2. checkpoint_timeout 秒間待ちます。 次のクエリを実行して現在の WAL LSN を取得し、結果をメモします。

     select pg_current_wal_lsn();
     

  3. 2 つの結果を使用する次のクエリを実行し、違いをギガバイト (GB) 単位で確認します。

     select round (pg_wal_lsn_diff ('LSN value when run second time', 'LSN value when run first time')/1024/1024/1024,2) WAL_CHANGE_GB;
     

• checkpoint_completion_target: この値は 0.9 に設定することをお勧めします。 たとえば、checkpoint_timeout が 5 分の場合に値を 0.9 にすると、チェックポイントを完了するターゲットが 270 秒 (0.9*300 秒) であることを示します。 値 0.9 を指定すると、かなり一貫性のある I/O 負荷となります。 checkpoint_completion_target に思い切った値を指定すると、サーバーの I/O 負荷が増加する可能性があります。

• checkpoint_timeout: checkpoint_timeout 値は、サーバーで設定されている既定値から増やすことができます。 値を増やすときは、これを増やすとクラッシュ後の復旧時間も増えることを考慮に入れてください。

中断を減らす自動バキュームを調整する

自動バキュームによって中断が頻繁に発生するシナリオでの監視とチューニングの詳細については、「Autovacuum チューニング」を参照してください。

ストレージを増やす

ストレージを増やすと、サーバーに IOPS を追加するときに役立ちます。 ストレージと関連する IOPS の詳細については、「計算とストレージのオプション」を参照してください。

関連するコンテンツ

• 自動バキュームのトラブルシューティングとチューニング
• 計算とストレージのオプション