そこで、本記事では性能問題発生時の調査に必要な情報を取得するための設定や、性能遅延時の分析に有用な拡張を紹介します。

パラメータ設定の対象メジャーバージョンはPostgreSQL 10以上としています。なお、検証例で使用しているPostgreSQLは PostgreSQL 18.6、OSはRocky Linux 9.5です。

OSについて

現在、PostgreSQLを使う時のOSの選択肢としてよくLinuxにするかWindowsにするかの選択があります。
新規構築でOS選択の自由度がある場合は、Linuxを推奨します。

主な理由は下記の三つです。

• 同一スペックのサーバであればLinuxのほうが性能がよい
• Linuxでは利用可能な拡張や周辺ツールの選択肢がWindowsより豊富である(今回紹介するpg_statsinfoもWindowsでは非対応)
• トラブル発生時の調査がLinuxの方が容易/Windowsでは困難なことが多い

Linuxでは性能面・運用面のメリットが多く、利用可能な拡張も豊富であるため、トラブル調査も進めやすくなります。

PostgreSQLログ関連パラメータ

PostgreSQLログに関してお勧めのパラメータ設定を紹介します。

ログ出力先

ログの出力先(log_destination)は、stderrがお勧めです。syslog を使う必要がある場合でも、stderrも含めて’stderr, syslog’に設定しましょう。syslog のみ設定するのは絶対に避けましょう。
stderrを含める時は、logging_collectorもonにしておく必要があります。

log_destination = 'stderr'
logging_collector = on

stderr をお勧めする理由は、archive_commandパラメータで設定したcpコマンドが実行される際の標準エラー出力もPostgreSQLログに含まれるからです。例えばコピー先のディスクの空き容量が無くcpコマンドが失敗した時のエラーメッセージが該当します。syslog の場合は、このメッセージはsyslogに出力されずに、log_destinationで設定されたファイルに出力されてしまいます。

また、syslogでは高負荷時などにPostgreSQLからのメッセージを取りこぼす可能性があるのもsyslogを避ける理由です。PostgreSQLマニュアルにも「syslogは、もし書き込みができなかったときメッセージの廃棄を選びます。」との記述があります。またsyslog側の機能としてレート制限があり、制限値以上のメッセージが到着した場合に"NNN messages lost due to rate-limiting"というメッセージでNNN行失われたことが伝えられます。高負荷時にこそPostgreSQLが出力するログを確認したいのに、syslogではメッセージが大量に出力される高負荷時にsyslog側でメッセージが省略されることが多々ありますので、syslogを使う必要がある場合は必ずstderrでもログを取得するようにしましょう。

チェックポイントの実行と自動VACUUM/ANALYZEの実行

PostgreSQLなどのデータベースでは一定間隔ごとにチェックポイントが実行されます。チェックポイントはshared_buffersで設定された共有バッファ上で変更されたがファイルシステム上のデータベースファイルにはまだ書き込まれていない、いわゆるダーティーバッファをすべてデータベースファイルに書き出すことで、チェックポイント終了時点のすべてのデータベースファイルで一貫性が取れている状態にすることが目的の処理です。
ダーティーバッファをすべてファイルに書き出す処理ですので、Disk I/Oを使用します。SQL実行などのクライアント側の処理への影響は程度の差はあれあります。SQL実行で何らかの影響を受けたかどうかの調査で、そのタイミングでチェックポイントが実行されていたかどうかを確認するために、チェックポイント実行(log_checkpoints)をPostgreSQLログに出力することは有用です。

log_checkpoints = on
# PostgreSQL 14までデフォルトoff、PostgreSQL 15からデフォルトon

自動VACUUMや自動ANALYZEの実行もチェックポイントと同様に、Disk I/Oを使用します。PostgreSQLログに出力する目的はチェックポイントと同様に、SQL実行時に自動VACUUMや自動ANALYZEが実行されていたかどうかを調査する観点もありますが、もう一つの観点としてSQLの実行計画が突然変わった時に、その直前で実行計画の策定に影響するオプティマイザ統計情報を更新する自動ANALYZEが実行されていたかどうかを確認する観点もあります。

log_autovacuum_min_duration = 0
# PostgreSQL 14までデフォルト-1(無効)、PostgreSQL 15からデフォルト10min(10分)

ロック待ち

突然SQLの実行が遅くなった時に、ロック待ちをしていたかどうかを確認したい場合があります。デフォルトではoff(無効)となっているlog_lock_waitsをon(有効)にしておくと、deadlock_timeoutで設定した時間(デフォルト1秒)ロック待ちをするとPostgreSQLログに出力されます。ただしdeadlock_timeoutの設定値が少なすぎるとマニュアルにも説明があるようにチェックの負荷がかかるため、本当にデッドロックが発生した場合に検知が遅くなるデメリットはありますが、チェックの負荷が軽減されるメリットもあるのでデフォルト(1秒)よりも長い時間、例えば5秒とか10秒とかを設定しましょう。下記例では10秒を設定しています。

log_lock_waits = on # デフォルト off
deadlock_timeout = 10s # デフォルト 1s

遅延SQL

log_min_duration_statement(デフォルト:-1(無効))に設定した時間以上実行にかかったSQLはPostgreSQLログに出力されます。
下記設定例では、10秒を設定していますので、10秒以上かかったSQLはPostgreSQLログに出力されます。

log_min_duration_statement = 10s # デフォルト-1(無効)

上記の設定をすべて実行した場合

上記の設定をすべて実行した場合、SQLの遅延が発生するとSQL文が実行時間と共にPostgreSQLログに出力されます。例えばSQL Aが11秒かかったことが分かり、その際、一緒にロック待ちのログが出ていれば、ロック待ちの影響で遅延が発生したことがわかります。
また、遅延が発生したタイミングで自動VACUUMもしくはチェックポイントが実行されていたとか、遅延が発生する直前に自動ANALYZEが実行されていたかもわかりますので、同じタイミングで実行されていた自動VACUUMやチェックポイントの可能性があるかないか、また自動ANALYZEにより実行計画を作成する元となるオプティマイザ統計情報が変更されて実行計画が変更された可能性があるかないかが判断可能となります。
しかし、SQLが遅延した場合に実際に実行計画が変化したのかどうかまではわかりません。SQLが遅延した時に実行計画の情報をPostgreSQLログに出力するauto_explainモジュールについて後で紹介します。

メモリ設定関連パラメータ

共有バッファ

PostgreSQLマニュアルには1GB以上物理メモリがあるサーバでのshared_buffersの妥当な初期値は物理メモリの25%という説明が記載されていますので、共有バッファはサーバの物理メモリの4分の1に設定しましょう。例えば、物理メモリが64GBならば16GBを設定します。下記設定例は、物理メモリが64GBの場合です。

shared_buffers = 16GB

サーバのメモリがどのように使用されるか、使用される比率について説明します。
PostgreSQLはOSのファイルシステム上にデータベースのファイルを作成しますので、PostgreSQLの共有メモリで全体の25%、OS側でファイルのキャッシュとして全体の25%、合わせると物理メモリ全体の半分(50%)がPostgreSQLのデータベースファイルで使われ、残りの半分(50%)でOS自体が使用するメモリとOSが起動するプロセス、そしてPostgreSQLのプロセスがメモリを使用します。

ワークメモリ

SQLを実行する際にソートやハッシュ検索などの処理ではPostgreSQLプロセスがwork_memで設定された値を上限としてメモリを使用しようとしますが、設定された値では足りない場合にディスクを使って読み書きをして処理をします。メモリ上の読み書きに比べてディスク上の読み書きは桁違いに遅いので、SQLの実行に影響しますので、サーバのメモリが不足しない程度にwork_memに大きな値を設定します。下記の例では、16MBを設定しています。

work_mem = 16MB

work_memで設定した値でメモリ上で処理が済んでいるかどうかを確認するには、ディスク上の処理が発生した場合にPostgreSQLログに出力するlog_temp_filesを0に設定して、SQLを実行します。ディスクを使用したら、ファイル削除時にPostgreSQLログに使用した一時ファイルが出力されます。

log_temp_files = 0 # デフォルト -1(無効)

postgresql.confで上記の設定をすると、ディスク上の処理がすべてPostgreSQLログに出てしまいますので、一時的にlog_temp_files=0に変更してpg_ctl reloadで設定を反映、ディスク上の使用有無をチェックするSQL文を実行、log_temp_files=-1に戻してpg_ctl reloadで設定を反映することで、調査期間の間だけPostgreSQLログに出力することが可能です。

また、特定のSQLを取り出してpsqlで実行可能な場合は、下記の例のようにセッション単位でlog_temp_files=0に設定してSQLを実行することも可能です。psqlの画面上に表示するためにclient_min_messagesも設定することで、LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp13483.0", size 10731520が表示されて一時ファイルが使用されていることが分かります。

db1=# SET log_temp_files = 0;
SET
db1=# SHOW log_temp_files;
log_temp_files
----------------
0
(1 row)

db1=# SET client_min_messages = log;
SET
db1=# EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pgbench_accounts ORDER BY abalance DESC;
LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp13483.0", size 10731520
QUERY PLAN

------------------------------------------------------------------------------------------------------------------------------
----
Sort (cost=16476.32..16726.32 rows=100000 width=97) (actual time=65.871..80.323 rows=100000.00 loops=1)
Sort Key: abalance DESC
Sort Method: external merge Disk: 10480kB
Buffers: shared hit=1704, temp read=1310 written=1313
-> Seq Scan on pgbench_accounts (cost=0.00..2701.00 rows=100000 width=97) (actual time=0.022..14.887 rows=100000.00 loops
=1)
Buffers: shared hit=1701
Planning:
Buffers: shared hit=73
Planning Time: 0.571 ms
Execution Time: 89.080 ms
(10 rows)

上記のSQLで一時ファイルのDisk I/Oを使用しないwork_memの値を調べるには、実行計画でDiskが出なくなるwork_memの値を、セッション単位で一時的に必要最小限の大きな値に設定して、実行計画を表示させます。下記例では、16MBに設定した時に、external merge Diskがquicksort Memoryに変わりましたので、このSQLの実行直前にセッション単位のSET文でSET work_mem ='16MB';に設定すればメモリ上のソートで性能向上が見込めます。

db1=# SHOW work_mem;
work_mem
----------
4MB
(1 row)

db1=# SET work_mem = '16MB';
SET
db1=# EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pgbench_accounts ORDER BY abalance DESC;
QUERY PLAN

------------------------------------------------------------------------------------------------------------------------------
----
Sort (cost=11005.82..11255.82 rows=100000 width=97) (actual time=38.479..51.692 rows=100000.00 loops=1)
Sort Key: abalance DESC
Sort Method: quicksort Memory: 14791kB
Buffers: shared hit=1701
-> Seq Scan on pgbench_accounts (cost=0.00..2701.00 rows=100000 width=97) (actual time=0.020..12.699 rows=100000.00 loops
=1)
Buffers: shared hit=1701
Planning Time: 0.084 ms
Execution Time: 56.287 ms
(8 rows)

SQL遅延時の対応について

auto_explain拡張を紹介する前に、SQLが遅延した時にどのような対応を取るのかについて説明します。

オプティマイザ統計情報の最新化と不要領域の整理

SQLの遅延が発生した時にまず実行してほしいのが、SQLの実行計画の基となっているオプティマイザ統計情報の最新化と、SQLの検索対象テーブルの不要領域の整理です。
SQLの検索対象となっているテーブル全て、特に対象テーブルのみに限定する必要が無い場合はデータベースに対してVACUUM (ANALYZE)を実行します。

下記実行例では、どのような実行状況なのかを表示するためにVERBOSEオプションを付けています。

VACUUM (ANALYZE,VERBOSE) 検索対象テーブル;

もしくは、対象データベースに接続した状態で、引数を省略するとデータベース全体に対してVACUUM (ANALYZE)が実行されます。

VACUUM (ANALYZE,VERBOSE);

上記コマンドの実行で、現在テーブルに入っているデータで実行計画を作成するベースとなるオプティマイザ統計情報を最新化するとともに、削除済みだがまだ回収されていない不要領域が回収されます。そのため、実行計画を策定するためのオプティマイザ統計情報がテーブルの最新状況を反映していない乖離した古い状態で、効率の悪い不適切な実行計画によりSQLが遅延していた場合は、統計情報が最新化された後の再実行では遅延が解消されます。

実行計画の取得

上記のVACUUM (ANALYZE)をSQLの対象テーブルすべてに対して実行しても性能が改善しない場合、例えば普段0.5秒程度で実行されているSQLが急に10秒とかかかるようになった時に取得が必要な情報がEXPLAIN (ANALYZE, BUFFERS) 遅延SQL;で出力される実行計画です。

EXPLAIN (ANALYZE, BUFFERS) 遅延SQL;

EXPLAINコマンドは引数のSQLをどのように実行するかの詳細ステップを書いた実行計画を出力するコマンドで、ANALYZEオプションは実際に実行した時間を出力、BUFFERSオプションはファイルアクセス時に共有バッファから読み込んだのかファイルから読み込んだのかの情報とアクセスしたバッファ数を出力します。

実行例を下記に示します。1回目はDB起動直後、2回目は連続して実行しました。2回の違いとして、shared read(Diskからの読み込み)がshared hit(共有バッファからの読み込み)になっていること、一度読み込まれて共有バッファからの読み込みになったので2回目の時間がPlanningもExecutionも短くなっていることが分かります。

$ psql db1
psql (18.6)
Type "help" for help.

db1=# EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pgbench_accounts;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------
Seq Scan on pgbench_accounts (cost=0.00..2640.00 rows=100000 width=97) (actual time=2.176..28.884 rows=100000.00 loops=1)
Buffers: shared read=1640
Planning:
Buffers: shared hit=44 read=11
Planning Time: 0.846 ms
Execution Time: 33.923 ms
(6 rows)

db1=# EXPLAIN (ANALYZE, BUFFERS) SELECT * FROM pgbench_accounts;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------
Seq Scan on pgbench_accounts (cost=0.00..2640.00 rows=100000 width=97) (actual time=0.069..9.271 rows=100000.00 loops=1)
Buffers: shared hit=1640
Planning Time: 0.070 ms
Execution Time: 17.789 ms
(4 rows)

db1=#

上記の実行結果を、通常の速い時に取っておき、遅延が発生した遅い時にも取れば、実行計画そのものが変わったのか実行計画は同一なのか、遅い時はどのステップでどの程度遅くなっているのかの比較ができて、通常の速い時とどう違って遅いのかの理由が分かります。

なお、どの実行計画のどの段階でどの列の結果を出力しているのかのオプションであるVERBOSEオプションもあわせて指定すると、実行計画がどのように動作しているのか分かりやすくなります。下記実行例では、Outputの行がVERBOSEオプションによって追加された情報になります。

db1=# EXPLAIN (ANALYZE, BUFFERS, VERBOSE) SELECT * FROM pgbench_accounts;
QUERY PLAN

------------------------------------------------------------------------------------------------------------------------------
-----
Seq Scan on public.pgbench_accounts (cost=0.00..2640.00 rows=100000 width=97) (actual time=0.018..11.627 rows=100000.00 loop
s=1)
Output: aid, bid, abalance, filler
Buffers: shared hit=1640
Planning:
Buffers: shared hit=60
Planning Time: 1.456 ms
Execution Time: 19.776 ms
(7 rows)

db1=#

拡張(EXTENSION)

PostgreSQLの⼤きな特徴として、様々な機能を追加できる拡張(EXTENSION)があります。
ここでは性能問題の調査や分析に役立つ代表的な拡張を紹介します。

拡張を使用するためには、拡張が入ったパッケージをPostgreSQLインストール時にあらかじめインストールしておき、CREATE EXTENSIONやshared_preload_libraries変更などの設定が必要ですが、そもそも拡張をインストールしていない場合は、拡張を使用する設定をする前に後から追加でインストールが必要となります。
しかし、既にシステムが本番稼働をした状況で、後から拡張をインストールをするのはハードルが高いので、後から使いたい時に使えるよう、PostgreSQLインストール時に一緒にインストールしておくのが望ましいです。

拡張の種類

PostgreSQL本体と一緒に同梱されているcontribモジュールと、contribモジュール以外(サードパーティー)モジュールがあります。

contribモジュールは、PostgreSQL本体と合わせてリリースされていますので、PostgreSQLサーバのインストール時に一緒にインストールしておきましょう。contribモジュールをインストールしておけば、後からcontribモジュールに含まれる拡張を導入することが可能です。contribモジュール以外の拡張は、サードパーティーモジュールと呼ばれ、現在はGitHubサイトで公開されていることが多いです。ダウンロード可能な形式はソースコードがメインで、リリース時点で公開されているRHELのrpmファイルもダウンロード可能な場合もあります。

auto_explain(contrib)

設定した時間以上かかったSQLの実行計画をPostgreSQLログに出力します。今回のこの記事で一番紹介したかったのはこのauto_explain拡張モジュールです。

サポートでよく「SQLが突然遅くなった。」という問い合わせをいただきますが、遅くなった時の情報が何もないため、なぜ遅くなったのかの原因調査が出来ません。問い合わせをいただいた時の返答はいつも「次回遅延が発生している間にEXPLAIN (ANALYZE, BUFFERS) SQL;を実行して実行計画を取得してください。」とお伝えしています。遅延している状況がずっと続いている、または定期的に遅延していてその時間帯が日中の場合はEXPLAIN (ANALYZE, BUFFERS) SQL;を手動で実行して実行結果を取得することは可能ですが、遅延の発生が真夜中であるとか、遅延がいつ発生するのかが不明な場合は人手でEXPLAIN (ANALYZE, BUFFERS) SQL;を実行することは困難です。そのような状況で一番役立つのがこのauto_explainです。

auto_explainの使い方について説明します。postgresql.confに下記の設定を追加して、PostgreSQLを再起動するとauto_explainが有効になって、例えば10秒以上かかるSQLが実行されると自動的にSQL実行時のEXPLAIN(ANALYZE, BUFFERS) SQL;の情報がPostgreSQLログに出力されます。

PostgreSQLログにauto_explainでの実行結果が出力されれば、性能悪化時と通常時の実行計画を比較できます。
下記はauto_explainを使うために必要な設定で、設定追加後PostgreSQLを再起動すると10秒以上かかったSQL文の実行計画がPostgreSQLログに出力されます。

shared_preload_libraries = 'auto_explain'
auto_explain.log_min_duration = 10s
auto_explain.log_analyze = on
auto_explain.log_buffers = on
auto_explain.log_timing = off # ノードごとの実行時間を取得する場合はon

なお、auto_explainの有効化はデータベースサーバ全体だけではなく、セッション単位でも下記の方法で有効化可能です。下記の例は、psqlで接続した後、

db1=# LOAD 'auto_explain';
LOAD
db1=# set auto_explain.log_min_duration = 0;
SET
db1=# set auto_explain.log_analyze = on;
SET
db1=# SELECT COUNT(*) FROM pgbench_accounts;
count
--------
100000
(1 row)

db1=#

上記の実行でのPostgreSQLログ出力は下記となります。

2026-10-06 20:51:58.504 JST [5786] LOG: duration: 7.090 ms plan:
Query Text: SELECT COUNT(*) FROM pgbench_accounts;
Aggregate (cost=2924.00..2924.01 rows=1 width=8) (actual time=7.080..7.081 rows=1.00 loops=1)
-> Seq Scan on pgbench_accounts (cost=0.00..2674.00 rows=100000 width=0) (actual time=0.008..4.326 rows=100000.00 loops=1)

※注：auto_explain.log_analyzeを有効(on)にすると、すべてのSQL実行で性能上のマイナスが起こり得ます。auto_explain.log_timing = offを追加することでノードごとの時間情報が無効になりますが行数の情報は取得でき性能面での損失が改善されますので、本番環境では通常はauto_explain.log_timingを無効にしておくことが望ましいと考えられます。
実際に遅延が発生し、ノードごとの時間情報も必要と判断した場合のみ、性能面でのデメリットを認識した上でauto_explain.log_timing = onに変更し、情報が取得でき次第速やかに無効(off)にする運用がよいでしょう。

auto_explain(F.3. auto_explain — 低速な問い合わせ実行計画のログ)
https://www.sraoss.co.jp/PostgreSQL/Manual/document/18/auto-explain.html

pg_hint_plan(サードパーティー)

なお、今回紹介している性能調査とは異なりますが、auto_explainでPostgreSQLログに出力した実行計画が性能悪化の原因であった場合、SQLに埋め込んだヒント句で強制的に実行計画を変更するpg_hint_planという拡張も紹介しておきます。
オプティマイザ統計情報を最新化しても実行計画の形が変わってしまってSQLの性能が悪化した場合、例えば結合方式が速い時はHash Joinなのに遅延時はNested Loopに変更されてしまったとか、複数テーブルある結合で速い時と遅い時でテーブルを結合する順番が異なるなどの場合に、強制的に速い時の実行計画にあわせるためにSQLにヒント句を埋め込んでヒント句の通りに実行計画を強制変更します。SQLにヒント句を埋め込まない指定も利用可能です。弊社ブログに解説がありますのでご参照ください。

pg_hint_plan (PostgreSQL 実行計画制御ツール)
https://www.sraoss.co.jp/tech-blog/pgsql/pg_hint_plan/

pg_stat_statements(contrib)

pg_stat_statementsは日常的にどのSQLが時間を使っているのかを把握するための拡張です。短い実行時間のSQLでも実行回数が多ければ合計実行時間は大きくなります。pg_stat_statementsはサーバで実行されたすべてのSQLのプラン生成時と実行時の統計情報を記録します。このモジュールはPostgreSQLログへの出力は無く、情報の参照は情報を取得しているデータベースに接続してpg_stat_statementsビューをSELECTする方法となります。

下記はpg_stat_statementsを使うために必要な設定で、設定追加後PostgreSQLを再起動した後、利用するデータベースに接続してCREATE EXTENSION pg_stat_statements;を実行すると、pg_stat_statementsビューが参照可能となります。

shared_preload_libraries = 'pg_stat_statements'

DB再起動後、下記を実行。

db1=# CREATE EXTENSION pg_stat_statements;
CREATE EXTENSION
db1=# \dx
List of installed extensions
Name | Version | Default version | Schema | Description

--------------------+---------+-----------------+------------+----------------------------------------------------------------
--------
pg_stat_statements | 1.12 | 1.12 | public | track planning and execution statistics of all SQL statements e
xecuted
plpgsql | 1.0 | 1.0 | pg_catalog | PL/pgSQL procedural language
(2 rows)

db1=#

PostgreSQLマニュアルの実行例を実行した例。合計実行時間(total_exec_time)の多い順から、SQL、呼び出し回数、合計実行時間、行数、算出したヒット率が表示されています。

db1=# \x
Expanded display is on.
db1=# SELECT query, calls, total_exec_time, rows, 100.0 * shared_blks_hit /
nullif(shared_blks_hit + shared_blks_read, 0) AS hit_percent
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 5;
-[ RECORD 1 ]---+-----------------------------------------------------------------------------------------------------
query | UPDATE pgbench_branches SET bbalance = bbalance + $1 WHERE bid = $2
calls | 3000
total_exec_time | 17180.62709200005
rows | 3000
hit_percent | 99.9982951155059245
-[ RECORD 2 ]---+-----------------------------------------------------------------------------------------------------
query | UPDATE pgbench_tellers SET tbalance = tbalance + $1 WHERE tid = $2
calls | 3000
total_exec_time | 14783.155679999958
rows | 3000
hit_percent | 99.9957805907172996
-[ RECORD 3 ]---+-----------------------------------------------------------------------------------------------------
query | UPDATE pgbench_accounts SET abalance = abalance + $1 WHERE aid = $2
calls | 3000
total_exec_time | 111.09148400000022
rows | 3000
hit_percent | 92.5940860215053763
-[ RECORD 4 ]---+-----------------------------------------------------------------------------------------------------
query | SELECT abalance FROM pgbench_accounts WHERE aid = $1
calls | 3000
total_exec_time | 28.88099300000003
rows | 3000
hit_percent | 100.0000000000000000
-[ RECORD 5 ]---+-----------------------------------------------------------------------------------------------------
query | INSERT INTO pgbench_history (tid, bid, aid, delta, mtime) VALUES ($1, $2, $3, $4, CURRENT_TIMESTAMP)
calls | 3000
total_exec_time | 21.792536000000027
rows | 3000
hit_percent | 100.0000000000000000

db1=#

pg_stat_statements(F.32. pg_stat_statements — SQL文のプラン生成時と実行時の統計情報を記録する)
https://www.sraoss.co.jp/PostgreSQL/Manual/document/18/pgstatstatements.html

性能問題の調査に役立つ情報の継続収集

性能問題の調査では、問題発生時の状況だけでなく、過去との比較も重要です。
そのためには PostgreSQL の統計情報や OS のリソース情報を継続的に収集しておくことが有効です。

収集方法としては、

• sysstat(sar)
• 各種監視ツール
• PostgreSQL向け収集ツール

などがあります。
その中でも PostgreSQL の統計情報と OS リソース情報をまとめて時系列で取得できるツールとしてpg_statsinfo があります。

pg_statsinfo(サードパーティー)

pg_statsinfo は PostgreSQL の統計情報やOSリソース情報を時系列で取得・保存するツールです。PostgreSQL 統計情報やOSリソース情報を時系列で取得するスナップショットを保存するためのリポジトリDBが必要となりますが、pg_statsinfoを使った運用をしていると何か性能問題が発生した時に過去の情報を参照できるのでとても便利です。上で紹介したpg_stat_statementsと、ヒント句を取得できるpg_store_plansと併用することでクエリの統計情報と実行計画も一緒に保存できるため、どのSQLが性能に影響していた可能性があるのか、また実行計画の変化によって性能が悪化した時も後から確認できます。
弊社ブログに解説がありますのでご参照ください。

pg_statsinfo(統計・OSリソース情報時系列取得保存ツール)
https://www.sraoss.co.jp/tech-blog/pgsql/pg_statsinfo/

pg_statsinfoは現在も有用なツールですが、監視製品やクラウド環境の監視機能などを利用して継続収集を行う方法も合わせてご検討ください。

まとめ

PostgreSQLの性能問題は、「遅くなった」という事実だけでは原因を特定できません。重要なのは、問題発生時に何が起きていたのかを後から分析できる情報を残しておくことです。

本記事では、チェックポイント、自動VACUUM、自動ANALYZE、ロック待ち、遅延SQLを記録するためのログ設定と、遅延時の実行計画を自動取得できるauto_explain、調査結果を踏まえて実行計画を制御できるpg_hint_plan、SQL実行統計を蓄積するpg_stat_statements、PostgreSQLの統計情報やOSリソース情報を時系列で取得・保存するpg_statsinfoを紹介しました。

特に、SQL性能問題の原因究明においては、遅延発生時のEXPLAIN (ANALYZE, BUFFERS)の取得が最も重要です。auto_explainを導入しておけば、人が操作できない時間帯に発生した遅延であっても、実行計画を記録できます。遅延時の実行計画が通常時の実行計画と異なる場合は、pg_hint_planにより強制的に通常時の実行計画に合わせることが可能となります。ただし、実行計画変更の根本原因が統計情報やデータ分布の変化にある場合もあり、pg_hint_planは原因調査や恒久対策を行った上で必要に応じて利用します。

PostgreSQLの性能問題への対応は、問題発生後に慌てて調査方法を考えるのではなく、平常時から必要な情報を取得できる状態を作っておくことが重要です。本記事がそのための設定見直しの参考になれば幸いです。

pg_statsinfo とは

pg_statsinfo は PostgreSQL の統計情報やOSリソース情報を時系列で取得・保存するツールです。複数スナップショットを取得してその期間のレポートが参照出来ます。

取得した情報はテキストファイル形式でレポート出力が可能ですが、pg_stats_reporter という Web ベースで参照が容易なツールが別途用意されており pg_statsinfo とあわせて pg_stats_reporter もインストールして使用することをお勧めします。

PostgreSQL 13までの公式サイトは[こちら]で、分かりやすいドキュメントも公式サイトにリンクがあります。(例: [pg_statsinfo 13 ドキュメント], [pg_stats_reporter 13 ドキュメント])
PostgreSQL 14以降の公式サイトは[GitHub]に移行しており、[マニュアル]も[ダウンロードサイト]もGitHub上にあります。

pg_statsinfo の機能

pg_statsinfo の主要な機能として以下のものがあります。

• 統計情報の取得機能
  PostgreSQL 統計情報やOSリソース情報をスナップショットとして時系列で取得してリポジトリDBに蓄積します。取得した情報から性能情報のレポートを出力したり、一定期間スナップショットを保持して古くなったスナップショットを削除するなどメンテナンス機能もあります。
• サーバログ分配機能
  csv形式で出力されたサーバログを加工して、 PostgreSQLログや syslog に出力することが可能です。またログの圧縮やローテーションも可能です。
• アラート機能
  リポジトリDB内に保持したアラートしきい値を超えた項目についてアラート出力することが可能です。

スナップショットとは

スナップショットとはとあるタイミングで取得した[統計情報]です。スナップショットを複数取得して異なるタイミングでの統計情報のトレンドの変化を把握したり、開始のスナップショットと終了のスナップショットを指定してその期間の性能情報のレポートを作成することが可能です。

リポジトリDBとは

pg_statsinfo は計測対象の PostgreSQL に導入しますが、取得したスナップショットはリポジトリDBと呼ばれるデータベースに保存します。独立したリポジトリDBを別途用意して pg_statsinfo 計測対象の PostgreSQL で取得した計測データをリポジトリDBに保存する構成も可能ですし、リポジトリDBは pg_statsinfo 計測対象の PostgreSQL の中に同居させることも可能です。
PostgreSQLを2台用意したアクティブ/スタンバイのストリーミングレプリケーション構成でリポジトリDBを同居する場合は、スタンバイ側計測データはスタンバイ側DB(自分自身)には書き込みが出来ませんので、常にプライマリに書き込むように接続先IPアドレスを設定する必要があります。
なお計測データをWeb画面で参照する pg_stats_reporter はリポジトリDBのサーバにインストールします。

バージョン構成

pg_statsinfo 3.3 までは複数の PostgreSQL バージョンがサポート対象でしたが、pg_statsinfo 10 以降は1つの PostgreSQL バージョンのみがサポート対象です。
また RHEL 8.x / CentOS 8.x がサポートされているバージョンは pg_statsinfo 12 と pg_statsinfo 13 です。

pg_stats_reporter はそれぞれの pg_statsinfo のバージョンに対応したバージョンが用意されています。

pg_statsinfo 11 on RHEL 8.x / CentOS 8.x

RHEL 8.x / CentOS 8.x 上での pg_statsinfo 11 については、rpm は用意されておらずソースコードはコンパイル時にエラーが出ますが、コンパイルエラーは libstatsinfo.c に

#include <sys/sysmacros.h>

の行を追加すればエラーは解消します。

pg_statsinfo インストール(rpmパッケージ)

pg_statsinfo のインストール方法は、rpm からのインストールとソースコードからのインストールの二つがありますが、今回は rpm からのインストールをご紹介します。
下記のインストールの実行例では1台のサーバ上で CentOS Linux release 8.3.2011, PostgreSQL 13.2, pg_statsinfo 13.0, pg_stats_reporter 13.0 を使用して説明します。
CentOS から直接インターネット接続が可能な環境を使用しています。
また PostgreSQL 13.2 はPostgreSQL公式サイトのrpmを使って既に設定済の環境を使用します。

pg_statsinfo rpmパッケージのインストール

pg_statsinfo 13.0 の rpm ファイル(pg_statsinfo-13.0-1.pg13.rhel8.x86_64.rpm)を[こちら]からダウンロードしてインストールします。

# dnf install pg_statsinfo-13.0-1.pg13.rhel8.x86_64.rpm
依存関係が解決しました。
=========================================================================================================================================
パッケージ アーキテクチャー バージョン リポジトリー サイズ
=========================================================================================================================================
インストール:
pg_statsinfo x86_64 13.0-1.pg13.rhel8 @commandline 758 k

トランザクションの概要
=========================================================================================================================================
インストール 1 パッケージ

合計サイズ: 758 k
インストール済みのサイズ: 1.2 M
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
準備 : 1/1
scriptletの実行中: pg_statsinfo-13.0-1.pg13.rhel8.x86_64 1/1
インストール : pg_statsinfo-13.0-1.pg13.rhel8.x86_64 1/1
scriptletの実行中: pg_statsinfo-13.0-1.pg13.rhel8.x86_64 1/1
検証 : pg_statsinfo-13.0-1.pg13.rhel8.x86_64 1/1
Installed products updated.

インストール済み:
pg_statsinfo-13.0-1.pg13.rhel8.x86_64

完了しました!
#

pg_statsinfo の設定 (postgresql.conf ファイル)

[公式ドキュメント]の「設定ファイル – postgresql.confの設定」に記載されている「推奨設定」の記載をpostgresql.conf ファイルに追加し、PostgreSQL 13.2 を再起動します。

$ cd $PGDATA
$ vi postgresql.conf (下記の内容を最後に追加)
#推奨設定
shared_preload_libraries = 'pg_statsinfo' # 事前ロードを行う

pg_statsinfo.snapshot_interval = 30min # スナップショットの取得間隔 (本検証では10minに設定します)
pg_statsinfo.enable_maintenance = 'on' # 自動メンテナンス設定
pg_statsinfo.maintenance_time = '00:02:00' # 自動メンテナンス実行時刻設定
pg_statsinfo.repolog_min_messages = disable # ログ蓄積機能の設定

log_filename = 'postgresql-%Y-%m-%d_%H%M%S.log' # ログファイル名を指定する
log_min_messages = 'log' # ログへ出力するメッセージレベル。
pg_statsinfo.syslog_min_messages = 'error' # syslogに出力するログレベルを指定する。
pg_statsinfo.textlog_line_prefix = '%t %p %c-%l %x %q(%u, %d, %r, %a) '
# pg_statsinfoがテキストログに出力する際、各行の先頭に追加される書式を指定する。log_line_prefixと同じ形式で指定する。
pg_statsinfo.syslog_line_prefix = '%t %p %c-%l %x %q(%u, %d, %r, %a) '
# pg_statsinfoがsyslog経由でログを出力する際、各行の先頭に追加される書式を指定する。

track_functions = 'all' # ストアドプロシージャの呼び出しに関する統計情報を収集する
log_checkpoints = on # チェックポイントを記録
log_autovacuum_min_duration = 0 # 自動バキュームを記録
#pg_statsinfo.long_lock_threshold = 30s # ロック競合情報に記録する対象の条件(閾値)を指定する
$ su -
# systemctl restart postgresql-13.service
#

pg_stats_reporter インストール(rpmパッケージ)

pg_stats_reporter も同一サーバ上で使えるようにインストールします。

pg_stats_reporter rpmパッケージのインストール

pg_stats_reporter 13.0 の rpm ファイル(pg_stats_reporter-13.0-1.el8.noarch.rpm)を[こちら]からダウンロードしてインストールします。

# dnf install pg_stats_reporter-13.0-1.el8.noarch.rpm
依存関係が解決しました。
=========================================================================================================================================
パッケージ アーキテクチャー バージョン リポジトリー サイズ
=========================================================================================================================================
インストール:
pg_stats_reporter noarch 13.0-1.el8 @commandline 2.9 M
依存関係のインストール:
apr x86_64 1.6.3-11.el8 appstream 125 k
apr-util x86_64 1.6.1-6.el8 appstream 105 k
centos-logos-httpd noarch 80.5-2.el8 baseos 24 k
httpd x86_64 2.4.37-30.module_el8.3.0+561+97fdbbcc appstream 1.7 M
httpd-filesystem noarch 2.4.37-30.module_el8.3.0+561+97fdbbcc appstream 37 k
httpd-tools x86_64 2.4.37-30.module_el8.3.0+561+97fdbbcc appstream 104 k
mod_http2 x86_64 1.15.7-2.module_el8.3.0+477+498bb568 appstream 154 k
nginx-filesystem noarch 1:1.14.1-9.module_el8.0.0+184+e34fea82 appstream 24 k
php x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 appstream 1.5 M
php-cli x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 appstream 3.1 M
php-common x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 appstream 661 k
php-pdo x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 appstream 122 k
php-pgsql x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 appstream 117 k
php-xml x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 appstream 188 k
弱い依存関係のインストール:
apr-util-bdb x86_64 1.6.1-6.el8 appstream 25 k
apr-util-openssl x86_64 1.6.1-6.el8 appstream 27 k
php-fpm x86_64 7.2.24-1.module_el8.2.0+313+b04d0a66 appstream 1.6 M
モジュールストリームの有効化中:
httpd 2.4
nginx 1.14
php 7.2

トランザクションの概要
=========================================================================================================================================
インストール 18 パッケージ

合計サイズ: 12 M
ダウンロードサイズの合計: 9.6 M
インストール済みのサイズ: 47 M
これでよろしいですか? [y/N]: y
パッケージのダウンロード:
(1/17): apr-util-bdb-1.6.1-6.el8.x86_64.rpm 405 kB/s | 25 kB 00:00
(2/17): apr-util-openssl-1.6.1-6.el8.x86_64.rpm 537 kB/s | 27 kB 00:00
(3/17): apr-1.6.3-11.el8.x86_64.rpm 959 kB/s | 125 kB 00:00
(4/17): apr-util-1.6.1-6.el8.x86_64.rpm 797 kB/s | 105 kB 00:00
：
(略)
：
検証 : centos-logos-httpd-80.5-2.el8.noarch 17/18
検証 : pg_stats_reporter-13.0-1.el8.noarch 18/18
Installed products updated.

インストール済み:
apr-1.6.3-11.el8.x86_64 apr-util-1.6.1-6.el8.x86_64
apr-util-bdb-1.6.1-6.el8.x86_64 apr-util-openssl-1.6.1-6.el8.x86_64
centos-logos-httpd-80.5-2.el8.noarch httpd-2.4.37-30.module_el8.3.0+561+97fdbbcc.x86_64
httpd-filesystem-2.4.37-30.module_el8.3.0+561+97fdbbcc.noarch httpd-tools-2.4.37-30.module_el8.3.0+561+97fdbbcc.x86_64
mod_http2-1.15.7-2.module_el8.3.0+477+498bb568.x86_64 nginx-filesystem-1:1.14.1-9.module_el8.0.0+184+e34fea82.noarch
pg_stats_reporter-13.0-1.el8.noarch php-7.2.24-1.module_el8.2.0+313+b04d0a66.x86_64
php-cli-7.2.24-1.module_el8.2.0+313+b04d0a66.x86_64 php-common-7.2.24-1.module_el8.2.0+313+b04d0a66.x86_64
php-fpm-7.2.24-1.module_el8.2.0+313+b04d0a66.x86_64 php-pdo-7.2.24-1.module_el8.2.0+313+b04d0a66.x86_64
php-pgsql-7.2.24-1.module_el8.2.0+313+b04d0a66.x86_64 php-xml-7.2.24-1.module_el8.2.0+313+b04d0a66.x86_64

完了しました!
#

pg_stats_reporter の設定 (httpd 起動設定)

pg_stats_reporterで使用するために、OS起動時に自動的にhttpdが起動するように設定します。

# systemctl start httpd
# systemctl enable httpd
Created symlink /etc/systemd/system/multi-user.target.wants/httpd.service → /usr/lib/systemd/system/httpd.service.
# systemctl status httpd
● httpd.service - The Apache HTTP Server
Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor preset: disabled)
Drop-In: /usr/lib/systemd/system/httpd.service.d
mqphp-fpm.conf
Active: active (running) since Tue 2021-03-30 15:22:36 JST; 1h 15min ago
Docs: man:httpd.service(8)
Process: 12032 ExecReload=/usr/sbin/httpd $OPTIONS -k graceful (code=exited, status=0/SUCCESS)
Main PID: 1293 (httpd)
Status: "Running, listening on: port 80"
Tasks: 213 (limit: 4816)
Memory: 29.2M
CGroup: /system.slice/httpd.service
tq 1293 /usr/sbin/httpd -DFOREGROUND
tq12052 /usr/sbin/httpd -DFOREGROUND
tq12053 /usr/sbin/httpd -DFOREGROUND
tq12054 /usr/sbin/httpd -DFOREGROUND
mq12055 /usr/sbin/httpd -DFOREGROUND

3月 30 15:22:27 c832011 systemd[1]: Starting The Apache HTTP Server...
3月 30 15:22:36 c832011 httpd[1293]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80:>
3月 30 15:22:36 c832011 systemd[1]: Started The Apache HTTP Server.
3月 30 15:23:02 c832011 httpd[1293]: Server configured, listening on: port 80
3月 30 16:07:01 c832011 systemd[1]: Reloading The Apache HTTP Server.
3月 30 16:07:09 c832011 httpd[12032]: AH00558: httpd: Could not reliably determine the server's fully qualified domain name, using fe80>
3月 30 16:07:09 c832011 systemd[1]: Reloaded The Apache HTTP Server.
3月 30 16:07:17 c832011 httpd[1293]: Server configured, listening on: port 80
#

pg_stats_reporter の設定 (pg_stats_reporter設定ファイル)

/etc ディレクトリ直下に pg_stats_reporter.ini ファイルがありますので repository DB setting section と書かれた箇所にリポジトリDBの情報を記入してください。検証環境では下記のように設定しました。

;=====================================
; repository DB setting section
;=====================================

;-------------------------------------
; repository1
;-------------------------------------

[repository1]

;-------------------------------------
; database connection
;-------------------------------------

host = localhost
port = 5432
dbname = postgres
username = postgres
password = password
;

pg_statsinfo の使い方

起動プロセスの確認

PostgreSQL のプロセスを確認すると、pg_statsinfo launcher と pg_statsinfod が起動されていることが分かります。

$ ps -ef | grep postgres | grep -v grep
postgres 1070 1 0 10:42 ? 00:00:00 /usr/pgsql-13/bin/postmaster -D /var/lib/pgsql/13/data/
postgres 1103 1070 0 10:42 ? 00:00:00 postgres: logger
postgres 1105 1070 0 10:42 ? 00:00:00 postgres: checkpointer
postgres 1106 1070 0 10:42 ? 00:00:00 postgres: background writer
postgres 1107 1070 0 10:42 ? 00:00:00 postgres: walwriter
postgres 1108 1070 0 10:42 ? 00:00:00 postgres: autovacuum launcher
postgres 1109 1070 0 10:42 ? 00:00:00 postgres: stats collector
postgres 1110 1070 0 10:42 ? 00:00:01 postgres: pg_statsinfo launcher
postgres 1111 1070 0 10:42 ? 00:00:00 postgres: logical replication launcher
postgres 1112 1110 0 10:42 ? 00:00:13 /usr/pgsql-13/bin/pg_statsinfod 1070
root 6501 6466 0 11:35 pts/0 00:00:00 su - postgres
postgres 6502 6501 0 11:35 pts/0 00:00:00 -bash
postgres 13338 1070 0 14:10 ? 00:00:00 postgres: postgres postgres [local] idle
postgres 13409 6502 0 14:12 pts/0 00:00:00 ps -ef

PostgreSQLログファイル

PostgreSQL ログディレクトリを確認すると、固定ファイル名のPostgreSQLログ(pg_statsinfo.log)が一つと、年月日時分秒が付いたCSVログ(.csv)とPostgreSQLログ(.log)と.copyの付いたPostgreSQLログ(.log.copy)があります。監視ソフトで設定する監視対象は固定ファイル名のPostgreSQLログとなります。

$ cd $PGDATA/log
$ ls -l
合計 932
drwx------. 2 postgres postgres 6 3月 23 15:32 log_archive
-rw------- 1 postgres postgres 44098 4月 14 14:12 pg_statsinfo.log
-rw------- 1 postgres postgres 65643 3月 23 16:15 postgresql-2021-03-23_153328.csv
-rw------- 1 postgres postgres 52741 3月 23 16:15 postgresql-2021-03-23_153328.log
-rw------- 1 postgres postgres 168 3月 23 15:33 postgresql-2021-03-23_153328.log.copy
(略)
-rw------- 1 postgres postgres 7047 4月 13 19:13 postgresql-2021-04-13_190131.csv
-rw------- 1 postgres postgres 5009 4月 14 10:42 postgresql-2021-04-13_190131.log
-rw------- 1 postgres postgres 166 4月 13 19:01 postgresql-2021-04-13_190131.log.copy
-rw------- 1 postgres postgres 57678 4月 14 14:12 postgresql-2021-04-14_104210.csv
-rw------- 1 postgres postgres 166 4月 14 10:42 postgresql-2021-04-14_104210.log

スナップショット取得(自動)

スナップショットはpg_statsinfo.snapshot_intervalパラメータで設定した値で自動的に取得されます。
今回検証環境では10minに設定していますので、10分おきにスナップショットが取得されます。

スナップショット取得(手動)

スナップショットは SELECT statsinfo.snapshot(‘コメント’)の実行でも手動で取得出来ます。
スナップショットの取得自体は非同期に実行されますので、コマンドプロンプトはすぐに返ってきてもスナップショットがまだ完了していない場合もあります。

$ psql -d postgres -c "SELECT statsinfo.snapshot('comment202104141602')"
snapshot
----------

(1 行)

$

スナップショット一覧

コマンドラインから pg_statsinfo -l を実行すると現在リポジトリに保存されているスナップショットの一覧が表示されます。

$ pg_statsinfo -l
----------------------------------------
Snapshot List
----------------------------------------
SnapshotID InstanceID Host Port Timestamp Comment Execute Time Size
-----------------------------------------------------------------------------------------------------------------------------------------
28 1 c832011 5432 2021-03-24 10:50:00 00:00:01 232 KiB
29 1 c832011 5432 2021-03-24 11:09:11 00:00:02 176 KiB
(略)
165 1 c832011 5432 2021-04-14 15:50:00 00:00:01 368 KiB
166 1 c832011 5432 2021-04-14 16:00:00 00:00:01 360 KiB
167 1 c832011 5432 2021-04-14 16:02:05 comment202104141602 00:00:01 368 KiB

簡易レポート機能

スナップショットの開始と終了を指定してテキスト形式のレポート出力が出来ます。レポートは標準出力に出ますので、適切なファイル名にリダイレクトして保存します。
下記の例では全てをレポート出力(All)としていますが、指定可能な種類は[コマンドライン機能の使い方]のレポート生成に記載されています。

$ pg_statsinfo -r All -b 165 -e 167 -h localhost -d postgres -p 5432 -U postgres > sireport165_167.txt
Password:
$ cat sireport165_167.txt
---------------------------------------------
STATSINFO Report (host: c832011, port: 5432)
---------------------------------------------

----------------------------------------
/* Summary */
----------------------------------------
Database System ID : 6940138282810842183
Host : c832011
Port : 5432
PostgreSQL Version : 13.2
Snapshot Begin : 2021-04-14 15:50:00
Snapshot End : 2021-04-14 16:02:05
Snapshot Duration : 00:12:05
Total Database Size : 151 MiB
Total Commits : 273
Total Rollbacks : 0

/** Alert **/
-----------------------------------
DateTime Message
--------------------------------------------------------------------------------

----------------------------------------
/* Database Statistics */
----------------------------------------
Database Name : postgres
Database Size : 52 MiB
Database Size Increase : 0 MiB
Commit/s : 0.335
Rollback/s : 0.000
Cache Hit Ratio : 99.4 %
Block Read/s (disk+cache) : 205.821
Block Read/s (disk) : 1.312
Rows Read/s : 1692.930
Temporary Files : 0
Temporary Bytes : 0 MiB
Deadlocks : 0
Block Read Time : 0.000 ms
Block Write Time : 0.000 ms

Database Name : test1
Database Size : 99 MiB
Database Size Increase : 0 MiB
Commit/s : 0.041
Rollback/s : 0.000
Cache Hit Ratio : 100.0 %
Block Read/s (disk+cache) : 6.675
Block Read/s (disk) : 0.000
Rows Read/s : 41.593
Temporary Files : 0
Temporary Bytes : 0 MiB
Deadlocks : 0
Block Read Time : 0.000 ms
Block Write Time : 0.000 ms

/** Transaction Statistics **/
-----------------------------------
DateTime Database Commit/s Rollback/s
-----------------------------------------------------------------
2021-04-14 16:00 postgres 0.308 0.000
2021-04-14 16:00 test1 0.038 0.000
2021-04-14 16:02 postgres 0.463 0.000
2021-04-14 16:02 test1 0.056 0.000

/** Database Size **/
-----------------------------------
DateTime Database Size
-----------------------------------------------------
2021-04-14 15:50 postgres 51.411 MiB
2021-04-14 15:50 test1 99.090 MiB
2021-04-14 16:00 postgres 51.770 MiB
2021-04-14 16:00 test1 99.090 MiB
2021-04-14 16:02 postgres 52.129 MiB
2021-04-14 16:02 test1 99.090 MiB

/** Recovery Conflicts **/
-----------------------------------
Database Conflict Tablespace Conflict Lock Conflict Snapshot Conflict Bufferpin Conflict Deadlock
-----------------------------------------------------------------------------------------------------------------
postgres 0 0 0 0 0
test1 0 0 0 0 0

----------------------------------------
/* Instance Activity */
----------------------------------------

/** WAL Statistics **/
-----------------------------------
WAL Write Total : 1.586 MiB
WAL Write Speed : 0.004 MiB/s
WAL Archive Total : 0 file(s)
WAL Archive Failed : 0 file(s)

-----------------------------------
DateTime Location Segment File Write Size Write Size/s Last Archived WAL
-------------------------------------------------------------------------------------------------------------------
2021-04-14 16:00 0/95B3B738 000000010000000000000095 0.838 MiB 0.001 MiB
2021-04-14 16:02 0/95BFAD18 000000010000000000000095 0.748 MiB 0.006 MiB

/** Instance Processes **/
-----------------------------------
DateTime Idle Idle In Xact Waiting Running
---------------------------------------------------------------------------
2021-04-14 15:50 100.0 % 0.0 % 0.0 % 0.0 %
2021-04-14 16:00 100.0 % 0.0 % 0.0 % 0.0 %
2021-04-14 16:02 100.0 % 0.0 % 0.0 % 0.0 %
Average 100.0 % 0.0 % 0.0 % 0.0 %

/** BGWriter Statistics **/
-----------------------------------
Written Buffers By BGWriter (Average) : 0.000 buffers/s
Written Buffers By BGWriter (Maximum) : 0.000 buffers/s
Written Buffers By Backend (Average) : 0.219 buffers/s
Written Buffers By Backend (Maximum) : 0.360 buffers/s
Backend Executed fsync (Average) : 0.000 sync/s
Backend Executed fsync (Maximum) : 0.000 sync/s

----------------------------------------
/* OS Resource Usage */
----------------------------------------

/** CPU Usage + Load Average **/
-----------------------------------
DateTime User System Idle IOwait Loadavg1 Loadavg5 Loadavg15
------------------------------------------------------------------------------------------
2021-04-14 16:00 0.5 % 0.3 % 99.2 % 0.0 % 0.020 0.010 0.000
2021-04-14 16:02 0.8 % 0.3 % 98.9 % 0.1 % 0.020 0.010 0.000
Average 0.7 % 0.3 % 99.1 % 0.1 % 0.020 0.010 0.000

/** IO Usage **/
-----------------------------------
Device Including TableSpaces Total Read Total Write Total Read Time Total Write Time Current IO Queue Total IO Time
----------------------------------------------------------------------------------------------------------------------------------------------
dm-0 {pg_default,pg_global} 17 MiB 18 MiB 412 ms 1571 ms 0.000 1983 ms

-----------------------------------
DateTime Device Read Size/s (Peak) Write Size/s (Peak) Read Time Rate Write Time Rate
---------------------------------------------------------------------------------------------------------------------------------
2021-04-14 16:00 dm-0 24.30 KiB ( 1416.00 KiB) 22.77 KiB ( 164.00 KiB) 0.1 % 0.2 %
2021-04-14 16:02 dm-0 20.33 KiB ( 271.20 KiB) 35.62 KiB ( 219.00 KiB) 0.0 % 0.4 %

/** Memory Usage **/
-----------------------------------
DateTime Memfree Buffers Cached Swap Dirty
-----------------------------------------------------------------------------------------
2021-04-14 15:50 113.38 MiB 3.09 MiB 390.30 MiB 0.26 MiB 0.19 MiB
2021-04-14 16:00 61.36 MiB 3.09 MiB 390.11 MiB 0.76 MiB 0.32 MiB
2021-04-14 16:02 80.42 MiB 3.09 MiB 395.30 MiB 0.76 MiB 0.33 MiB

----------------------------------------
/* Disk Usage */
----------------------------------------

/** Disk Usage per Tablespace **/
-----------------------------------
Tablespace Location Device Used Avail Remain
-----------------------------------------------------------------------------------------------------------
pg_default /var/lib/pgsql/13/data 253:0 6470 MiB 10923 MiB 62.8 %
pg_global /var/lib/pgsql/13/data 253:0 6470 MiB 10923 MiB 62.8 %

/** Disk Usage per Table **/
-----------------------------------
Database Schema Table Size Table Reads Index Reads Toast Reads
---------------------------------------------------------------------------------------------------------------
postgres statsrepo column_20210414 5 MiB 642 29 0
postgres statsrepo index_20210414 0 MiB 67 2 0
：
(略)
：
postgres statsrepo database 0 MiB 9 0 0
postgres statsrepo setting 0 MiB 3 2 0

----------------------------------------
/* Long Transactions */
----------------------------------------
PID Client Address Xact Start Duration Query
-----------------------------------------------------------------------------------------

----------------------------------------
/* Notable Tables */
----------------------------------------

/** Heavily Updated Tables **/
-----------------------------------
Database Schema Table INSERT Rows UPDATE Rows DELETE Rows Total Rows HOT Ratio(%)
-----------------------------------------------------------------------------------------------------------------------------
postgres statsrepo column_20210414 2892 0 0 2892 0.0
postgres statsrepo table_20210414 166 0 0 166 0.0
postgres statsrepo function 162 0 0 162 0.0
：
(略)
：
postgres statsrepo memory 2 0 0 2 0.0
postgres statsrepo xlog 2 0 0 2 0.0

/** Heavily Accessed Tables **/
-----------------------------------
Database Schema Table Seq Scans Read Rows Read Rows/Scan Cache Hit Ratio(%)
-----------------------------------------------------------------------------------------------------------------------
postgres statsrepo column_20210413 4 4992 1248.000 93.2
postgres statsrepo table_20210326 6 2286 381.000 99.3
：
(略)
：
postgres statsrepo instance 106 106 1.000 100.0
postgres statsrepo alert 2 2 1.000 100.0

/** Low Density Tables **/
-----------------------------------
Database Schema Table Live Tuples Logical Pages Physical Pages Logical Page Ratio(%)
----------------------------------------------------------------------------------------------------------------------------
test1 public pgbench_accounts 500000 8197 8476 96.7
test1 public pgbench_history 283914 1809 1809 100.0

/** Correlation **/
-----------------------------------
Database Schema Table Column Correlation
---------------------------------------------------------------------------------------
test1 public pgbench_branches bid -0.600
postgres statsrepo column_20210413 tbl -0.200
test1 public pgbench_tellers tid -0.059
：
(略)
：
postgres statsrepo function snapid 1.000
postgres statsrepo table_20210405 snapid 1.000

----------------------------------------
/* Checkpoint Activity */
----------------------------------------
Total Checkpoints : 3
Checkpoints By Time : 3
Checkpoints By WAL : 0
Written Buffers Average : 105.667
Written Buffers Maximum : 133.000
Write Duration Average : 10.661 sec
Write Duration Maximum : 13.404 sec
----------------------------------------
/* Autovacuum Activity */
----------------------------------------

/** Vacuum Basic Statistics (Average) **/
-----------------------------------
Table Count Removed Rows Remain Rows Remain Dead Index Scans Duration Duration(Max) Cancels
-------------------------------------------------------------------------------------------------------------------------------------------

/** Vacuum I/O Statistics (Average) **/
-----------------------------------
Table Page Hit Page Miss Page Dirty Read Rate Write Rate
-----------------------------------------------------------------------------------------------------

/** Analyze Statistics **/
-----------------------------------
Table Count Duration(Total) Duration(Avg) Duration(Max) Last Analyze Time Cancels Mod Rows(Max)
---------------------------------------------------------------------------------------------------------------------------------------------
postgres.statsrepo.column_20210414 1 0.280 s 0.280 s 0.280 s 2021-04-14 16:00:50 0 2892
postgres.statsrepo.index_20210414 1 0.040 s 0.040 s 0.040 s 2021-04-14 15:50:50 0 180
postgres.statsrepo.inherits 1 0.010 s 0.010 s 0.010 s 2021-04-14 16:00:50 0 360

----------------------------------------
/* Query Activity */
----------------------------------------

/** Functions **/
-----------------------------------
OID Database Schema Function Calls Total Time Self Time Time/Call
----------------------------------------------------------------------------------------------------------------------
16990 postgres statsrepo partition_snapshot_insert 3178 470.809 ms 470.809 ms 0.148 ms
16984 postgres statsrepo get_snap_date 3178 235.482 ms 235.482 ms 0.074 ms
：
(略)
：
16960 postgres statsrepo get_heavily_accessed_tables 2 9.207 ms 8.761 ms 4.604 ms
16975 postgres statsrepo get_bgwriter_tendency 4 8.280 ms 4.834 ms 2.070 ms

/** Statements **/
-----------------------------------
User Database Calls Total Time Time/Call Block Read Time Block Write Time Query
------------------------------------------------------------------------------------------------------------------------

/** Plans **/
-----------------------------------
Query ID Plan ID User Database Calls Total Time Time/Call Block Read Time Block Write Time
-----------------------------------------------------------------------------------------------------------------------------------------

----------------------------------------
/* Lock Conflicts */
----------------------------------------
Database Schema Relation Duration Blockee PID Blocker PID Blocker GID
Blockee Query
Blocker Query
--------------------------------------------------------------------------------------------------------

----------------------------------------
/* Replication Activity */
----------------------------------------

/** Current Replication Status **/
-----------------------------------

----------------------------------------
/* Setting Parameters */
----------------------------------------
Name Setting Unit Source
-------------------------------------------------------------------------------------------------------
TimeZone Asia/Tokyo configuration file
default_text_search_config pg_catalog.english configuration file
lc_messages C configuration file
log_autovacuum_min_duration 0 ms configuration file
log_checkpoints on configuration file
log_destination csvlog override
log_min_messages log configuration file
log_rotation_size 0 kB configuration file
log_timezone Asia/Tokyo configuration file
log_truncate_on_rotation on configuration file
logging_collector on override
max_stack_depth 2048 kB environment variable
password_encryption scram-sha-256 configuration file
pg_statsinfo.repolog_min_messages disable configuration file
pg_statsinfo.syslog_line_prefix %t %p %c-%l %x %q(%u, %d, %r, %a) configuration file
pg_statsinfo.syslog_min_messages error configuration file
pg_statsinfo.textlog_line_prefix %t %p %c-%l %x %q(%u, %d, %r, %a) configuration file
server_encoding UTF8 override
shared_buffers 16384 8kB configuration file
shared_preload_libraries pg_statsinfo configuration file
track_functions all configuration file
wal_buffers 512 8kB override

----------------------------------------
/* Schema Information */
----------------------------------------

/** Tables **/
-----------------------------------
Database Schema Table Columns Rows Size Size Incr Table Scans Index Scans
-----------------------------------------------------------------------------------------------------------------------------
test1 public pgbench_accounts 4 500000 66 MiB 0 MiB 0 0
test1 public pgbench_branches 3 5 0 MiB 0 MiB 0 0
test1 public pgbench_history 6 283914 14 MiB 0 MiB 0 0
test1 public pgbench_tellers 4 50 0 MiB 0 MiB 0 0

/** Indexes **/
-----------------------------------
Database Schema Index Table Size Size Incr Index Scans Rows/Scan Disk Reads Cache Reads Index Key
-------------------------------------------------------------------------------------------------------------------------------------------------------------
test1 public pgbench_accounts_pkey pgbench_accounts 10 MiB 0 MiB 0 0.000 0 0 aid
test1 public pgbench_branches_pkey pgbench_branches 0 MiB 0 MiB 0 0.000 0 0 bid
test1 public pgbench_tellers_pkey pgbench_tellers 0 MiB 0 MiB 0 0.000 0 0 tid

----------------------------------------
/* Profiles */
----------------------------------------
Processing Executes
---------------------------------------------

pg_stats_reporter の使い方

Webレポート

下記のURLへアクセスすると、pg_stats_reporterのレポート画面が出ますので、ブラウザからアクセスして色々操作をしてみてください。

http://<ホスト名>/pg_stats_reporter/pg_stats_reporter.php

pg_stats_reporter のサンプル画面は[こちら]です。

終わりに

今回は pg_statsinfo と pg_stats_reporter を1台のサーバに導入して使い始めることができるところまで紹介しました。
日常的なモニタリングは何かが起こった時の調査に大いに役立ちますので、ぜひ導入を検討してみてください。