PostgreSQL監視メトリクスクエリ辞書

更新日: 2026-03-14
対象資料: PostgreSQL 公式ドキュメント / 27.2 Statistics Monitoring

1. この資料の目的

このメモは、PostgreSQL を監視するときによく使う統計ビューとクエリを、初心者向けにまとめたものです。

「どの画面やSQLを見ればよいか分からない」
「専門用語が多くて読みづらい」
という場面で、最初の参照先として使うことを想定しています。

2. まず覚えたい用語

セッション

DBに接続している1つ1つの利用者や処理のことです。
アプリやSQLクライアントが接続すると、通常は1接続ごとに1セッションできます。

待機イベント

処理が何かを待って止まっている状態です。
たとえば、次のような理由で待つことがあります。

データの読み書きが終わるのを待っている
他の処理が使っている行やテーブルの解放を待っている
ネットワークや送信先の応答を待っている

ロック

同じデータを同時に壊さないようにするための「使用中マーク」のようなものです。
ロック自体は普通の仕組みですが、長く待たされると遅延や詰まりの原因になります。

レプリケーション

DBの内容を別サーバーへコピーし続ける仕組みです。
本番DBから待機系DBへデータを送る用途でよく使います。

WAL

データ変更を記録するログです。
障害復旧やレプリケーションで使われます。更新が多いとWALも増えます。

VACUUM

更新や削除で不要になった領域を整理する仕組みです。
不足するとテーブルがふくらみやすくなり、性能劣化の原因になります。

ANALYZE

PostgreSQL が実行計画を決めるための統計情報を更新する処理です。
古いままだと、効率の悪いSQL実行につながることがあります。

累積値

起動後または統計リセット後から、ずっと足し上がっていく値です。
監視では「今の値」ではなく「前回との差分」を見るのが基本です。

3. 最初に見るべきビュー

迷ったら、まず次の5つを見ると全体像をつかみやすいです。

pg_stat_activity
- 今、誰が何をしているかを見る
pg_stat_database
- DB全体の忙しさやエラー傾向を見る
pg_stat_user_tables
- テーブルの更新状況や肥大の気配を見る
pg_stat_user_indexes
- インデックスが使われているかを見る
pg_stat_replication
- 待機系DBへのデータ転送遅れを見る

4. 監視メトリクス辞書

ビュー	何を見るものか	よく使う列	初心者向けの見方	公式リンク
`pg_stat_activity`	今つながっている接続と実行中SQL	`usename`, `state`, `wait_event`, `query_start`, `query`	遅いSQLや詰まっている処理を見つける	pg_stat_activity
`pg_stat_database`	DB全体の累積統計（起動後から足し上がる値）	`xact_commit`, `xact_rollback`, `blks_read`, `blks_hit`, `temp_bytes`, `deadlocks`	忙しさ、失敗、キャッシュ効率を見る	pg_stat_database
`pg_stat_user_tables`	テーブルごとの利用状況	`seq_scan`, `idx_scan`, `n_live_tup`, `n_dead_tup`, `last_autovacuum`	フルスキャンが多い表や肥大気味の表を探す	pg_stat_user_tables
`pg_stat_user_indexes`	インデックス（検索を速くする索引）の利用状況	`idx_scan`, `idx_tup_read`, `idx_tup_fetch`	使われていないインデックス候補を探す	pg_stat_user_indexes
`pg_stat_replication`	レプリケーション（別サーバーへのコピー）の状態	`state`, `write_lag`, `flush_lag`, `replay_lag`	待機系への反映遅れを確認する	pg_stat_replication
`pg_stat_wal`	WAL（更新ログ）の増え方	`wal_records`, `wal_fpi`, `wal_bytes`	更新量が急増していないかを見る	pg_stat_wal
`pg_stat_io`	I/O（ディスク読み書き）の詳細	`backend_type`, `object`, `context`, `reads`, `writes`, `fsyncs`	誰が多く読み書きしているかを見る	pg_stat_io
`pg_statio_user_tables`	テーブル単位のI/O（ディスク読み書き）	`heap_blks_read`, `heap_blks_hit`	テーブルごとのキャッシュ効率を見る	pg_statio_user_tables
`pg_stat_user_functions`	関数の実行統計	`calls`, `total_time`, `self_time`	重い関数を探す	pg_stat_user_functions
`pg_stat_archiver`	WALアーカイブ（ログ退避）の成否	成功回数、失敗回数など	アーカイブに失敗していないか見る	pg_stat_archiver

5. まず使うクエリ集

5.1 長時間動いているSQLを探す

SELECT
  pid,
  datname,
  usename,
  state,
  wait_event_type,
  wait_event,
  now() - query_start AS duration,
  query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

何が分かるか:

今まさに長く動いているSQL
途中で何かを待って止まっているセッション

見方:

duration が長いものから確認します
wait_event が入っていれば、何かを待っている可能性があります
state = active なら実行中、idle は何もしていない待機状態です

5.2 待ちが発生しているセッションを見る

SELECT
  pid,
  usename,
  datname,
  state,
  wait_event_type,
  wait_event,
  query
FROM pg_stat_activity
WHERE wait_event_type IS NOT NULL
ORDER BY query_start;

何が分かるか:

何かを待って止まっているセッション

見方:

長く待っているものは、詰まりの原因候補です
ロック待ち（他の処理が先に同じデータを使っていて待たされている状態）なら、詰まりの可能性があります

5.3 DB全体のキャッシュ効率を見る

SELECT
  datname,
  blks_hit,
  blks_read,
  ROUND(
    100.0 * blks_hit / NULLIF(blks_hit + blks_read, 0),
    2
  ) AS cache_hit_ratio_pct
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY cache_hit_ratio_pct ASC;

何が分かるか:

メモリ上のキャッシュがどれくらい効いているか

見方:

一般に高いほど、ディスク読み込みが少なく効率的です
低すぎる場合は、読み込み負荷やメモリ不足の可能性があります

5.4 ロールバック率を見る

SELECT
  datname,
  xact_commit,
  xact_rollback,
  ROUND(
    100.0 * xact_rollback / NULLIF(xact_commit + xact_rollback, 0),
    2
  ) AS rollback_ratio_pct
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY rollback_ratio_pct DESC;

何が分かるか:

正常終了せず取り消された処理が多いか

見方:

ロールバック（途中までの処理を取り消すこと）率が高い場合、アプリ側エラーや再試行の多発を疑います

5.5 一時ファイルを多く使うDBを見る

SELECT
  datname,
  temp_files,
  pg_size_pretty(temp_bytes) AS temp_bytes
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY temp_bytes DESC;

何が分かるか:

一時的な作業用ファイルを多く使っているDB

見方:

ソートや集計が重いと増えやすいです
多すぎるとディスクI/O増加につながります

5.6 デッドロック（お互いに待ち合って進めなくなる状態）発生数を見る

SELECT
  datname,
  deadlocks
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY deadlocks DESC;

何が分かるか:

お互いに待ち合って処理が進めなくなった回数

補足:

デッドロック（お互いに待ち合って進めなくなる状態）は「AがBを待ち、BもAを待つ」ような状態です
発生するとどちらかの処理が失敗させられます

5.7 フルスキャンが多いテーブルを見る

SELECT
  schemaname,
  relname,
  seq_scan,
  idx_scan,
  n_live_tup
FROM pg_stat_user_tables
ORDER BY seq_scan DESC
LIMIT 20;

何が分かるか:

インデックスを使わず、表全体を読んでいる回数が多いテーブル

見方:

seq_scan が多いから必ず悪い、ではありません
ただし大きい表で多い場合は、インデックスやSQL見直し候補です

5.8 Dead tuple（更新や削除で不要になった古い行）が多いテーブルを見る

SELECT
  schemaname,
  relname,
  n_live_tup,
  n_dead_tup,
  ROUND(
    100.0 * n_dead_tup / NULLIF(n_live_tup + n_dead_tup, 0),
    2
  ) AS dead_tuple_ratio_pct,
  last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

何が分かるか:

更新や削除の結果、不要データがたまりつつあるテーブル

見方:

n_dead_tup（不要になった古い行の推定数）が多いのに last_autovacuum が古い場合は要注意です
放置すると表がふくらみやすくなります

5.9 VACUUM（不要領域の掃除） / ANALYZE（統計情報の更新）が古いテーブルを見る

SELECT
  schemaname,
  relname,
  last_vacuum,
  last_autovacuum,
  last_analyze,
  last_autoanalyze
FROM pg_stat_user_tables
ORDER BY COALESCE(last_autoanalyze, last_analyze, last_autovacuum, last_vacuum) NULLS FIRST
LIMIT 50;

何が分かるか:

長い間メンテナンスされていないテーブル

見方:

更新が多い表なのに日時が古い場合は要確認です

5.10 使われていない可能性があるインデックス（検索を速くするための索引）を見る

SELECT
  schemaname,
  relname AS table_name,
  indexrelname AS index_name,
  idx_scan
FROM pg_stat_user_indexes
ORDER BY idx_scan ASC, indexrelname;

何が分かるか:

あまり使われていないインデックス候補

注意:

idx_scan = 0 だけで削除してはいけません
制約用、月次バッチ用、障害時の特殊クエリ用などの可能性があります

5.11 テーブルごとのキャッシュ効率（メモリ上でどれだけ読めているか）を見る

SELECT
  schemaname,
  relname,
  heap_blks_read,
  heap_blks_hit,
  ROUND(
    100.0 * heap_blks_hit / NULLIF(heap_blks_hit + heap_blks_read, 0),
    2
  ) AS heap_hit_ratio_pct
FROM pg_statio_user_tables
ORDER BY heap_hit_ratio_pct ASC NULLS FIRST
LIMIT 20;

何が分かるか:

どのテーブルがディスクから多く読まれているか

見方:

大きな表で比率が低い場合は、負荷源の候補になります

5.12 重い関数を探す

SELECT
  schemaname,
  funcname,
  calls,
  ROUND(total_time::numeric, 2) AS total_time_ms,
  ROUND(self_time::numeric, 2) AS self_time_ms,
  ROUND((total_time / NULLIF(calls, 0))::numeric, 2) AS avg_time_ms
FROM pg_stat_user_functions
ORDER BY total_time DESC
LIMIT 20;

何が分かるか:

呼ばれる回数が多い関数
1回あたりが重い関数

5.13 レプリケーション（別サーバーへのコピー）遅延を見る

SELECT
  application_name,
  client_addr,
  state,
  sync_state,
  write_lag,
  flush_lag,
  replay_lag
FROM pg_stat_replication
ORDER BY application_name;

何が分かるか:

本番側から待機側への反映遅れ

見方:

replay_lag が大きいと、待機系DBが最新に追いついていません

5.14 WAL（更新ログ）の増加量を見る

SELECT
  wal_records,
  wal_fpi,
  pg_size_pretty(wal_bytes) AS wal_bytes
FROM pg_stat_wal;

何が分かるか:

変更ログがどれくらい増えているか

見方:

更新系処理が増えると WAL も増えやすいです
監視では差分で見るのが基本です

5.15 `pg_stat_io` でI/O（ディスク読み書き）の多い処理を見る

SELECT
  backend_type,
  object,
  context,
  reads,
  read_time,
  writes,
  write_time,
  fsyncs,
  fsync_time
FROM pg_stat_io
ORDER BY reads DESC, writes DESC;

何が分かるか:

どの種類の処理が多く読み書きしているか

補足:

backend_type（そのI/Oを行っている処理の種類）は、どのタイプの処理が負荷を出しているかを見る手がかりです
たとえば通常クエリ、バックグラウンド処理、VACUUM などを切り分けられます

6. 監視での基本的な見方

累積値（起動後から足し上がっていく値）は差分で見る

xact_commit や wal_bytes は、時間とともに増え続ける累積値です。
そのため監視では、次のように扱います。

1分前との差分を取る
5分平均で変化量を見る
監視ツール側で rate/sec を計算する

1つの値だけで決めつけない

たとえば次のように組み合わせて見ると判断しやすくなります。

pg_stat_activity + wait_event
- 今、何か待って詰まっているかを見る
pg_stat_user_tables.n_dead_tup + last_autovacuum
- 表がふくらみ気味で、しかも掃除が追いついていないかを見る
pg_stat_database.temp_bytes
- 重い集計やソートが増えていないかを見る
pg_stat_user_indexes.idx_scan
- 使われていないインデックス候補かを見る

7. まずはこれだけ見ればよい簡易チェック

日常確認なら、最初は次の3本でも十分です。

長時間SQL確認

SELECT pid, usename, now() - query_start AS duration, state, wait_event, query
FROM pg_stat_activity
WHERE state <> 'idle'
ORDER BY duration DESC;

DB全体の状態確認

SELECT datname, xact_commit, xact_rollback, deadlocks, temp_files, temp_bytes
FROM pg_stat_database
WHERE datname IS NOT NULL
ORDER BY datname;

テーブル肥大（不要な古い行がたまって表がふくらむこと）の気配確認

SELECT schemaname, relname, n_live_tup, n_dead_tup, last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

8. 公式リンク集

9. 補足

本資料は 2026-03-14 時点の current ドキュメントをもとに整理しています
実際に使える列は PostgreSQL のバージョン差分に注意してください
pg_stat_io のように比較的新しいビューは、運用中バージョンで存在確認をしてから使ってください