PostgreSQLのシステムメトリクス
イメージしてみて、君のPostgreSQLサーバーはレストランみたいなもんで、僕らは監査役。レストランが安定して動くには、どれだけの材料（CPU、メモリ、ディスク）が使われてるか、どれくらいの頻度で足りなくなるか、誰がそれを消費してるかをちゃんと把握しないとダメなんだ。もしこのポイントを見逃すと、僕らの「レストラン」は注文を受けすぎてパンクしたり、突然昼間にクラッシュしたりするかも。だからこそ、システムメトリクスを理解するのは超大事なんだよ。
PostgreSQLを監視するための主なメトリクス：
- CPU: クエリ実行にどれだけCPUタイムが使われてるかを示す。
- メモリ（RAM）: PostgreSQLがどのようにメモリを使ってるか（クエリキャッシュも含む）を示す。
- ディスク容量: これは一番予想しやすいよね。ディスクが許す以上のデータは保存できない。
僕らのゴールは、PostgreSQLのシステムメトリクスをチェックして読み解くスキルを身につけて、パフォーマンスやリソース不足のトラブルを避けることだよ。
CPU使用率の監視
CPUはサーバーの心臓部。PostgreSQLは複雑なクエリの実行だけじゃなく、autoanalyzeやautovacuumみたいなバックグラウンドタスクでもCPUを使う。もし君のDBが食いしん坊みたいにCPUをガツガツ「食べて」たら、そろそろ介入のタイミングかも。
- システムツールの利用。
まずは、PostgreSQLがシステムレベルでどれだけCPUを使ってるかを調べよう。Linuxならtopやhtopコマンドが使えるよ。
PostgreSQLのプロセスを探してみて（たいていはDB名が入ってる）。例えば、postgres: postgres [your_query]みたいなやつ。
%CPUカラムに注目して。もしずっと「振り切れてる」なら、それは警告サインだよ。
- PostgreSQLからCPU負荷を分析する。
PostgreSQLには負荷を監視するためのビルトインビューがある。一番便利なのはpg_stat_activityで、アクティブなクエリが見れるよ。
クエリ例：
SELECT pid, usename, query, state, now() - query_start AS duration
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY duration DESC;
ここで大事なのは？
state = 'active'は今実行中のクエリだけを表示する。durationはクエリがどれだけ長くCPUを使ってるかを示す。
実践アドバイス：
もしやたら長いクエリがあったら、どのインデックスが使われてるか再チェックしよう。問題のあるプロセスはpg_terminate_backendで終了させることもできるよ。
終了例：
SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'active' AND duration > interval '10 minutes';
メモリ使用率の監視
メモリはPostgreSQLにとって2番目に重要なリソース。特にデータキャッシュに関してはね。PostgreSQLは（work_memやshared_buffersパラメータを通じて）メモリをガンガン使って処理を速くしてる。
- PostgreSQLの主なメモリパラメータ：
shared_buffers: PostgreSQLが使うメインのメモリ領域。だいたいサーバーメモリの25〜40%くらいを占める。work_mem: 1クエリ内でのソートやハッシュ処理用のメモリ。値が大きいほど、一時処理をメモリ内で（ディスクじゃなく）できる。
- 現在のメモリ設定をチェック。
PostgreSQLで今どんなメモリ設定になってるかは、次のコマンドで見れるよ：
SHOW shared_buffers;
SHOW work_mem;
出力例：
1GB
4MB
これは、shared_buffersに1GB、各ソート/ハッシュ処理に4MB割り当てられてるってこと。
pg_stat_activityでメモリ監視
今の接続がどれだけメモリを使ってるかもチェックできる。こんなクエリが便利だよ：
SELECT pid, usename, state, backend_start, pg_size_pretty(pg_backend_memory_contexts_size(pid)) AS memory_used
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY memory_used DESC;
このクエリで、各アクティブ接続がどれだけメモリを使ってるかが分かる。
ヒント： もし1つの接続がやたらメモリを食ってたら、そのクエリでソートや集約処理が最適化できないか見直してみて。
ディスク容量の監視
ディスクはPostgreSQLにとって最後のリソースタンク。メモリやCPUが十分でも、データやトランザクションログ（WAL）、一時ファイルの保存にはディスクが必要だよ。
- データベースサイズのチェック。
まずは基本から：DBのサイズを調べよう。
SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;
このクエリは何をする？
今のDB全体のサイズを分かりやすいフォーマット（MBやGB）で表示するよ。
- テーブルやインデックスのサイズチェック。
DB内の「ヘビー級」を調べるには、これを使おう：
SELECT relname AS table_name, pg_size_pretty(pg_total_relation_size(relid)) AS total_size
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;
出力例：
| table_name | total_size |
|---|---|
| orders | 1 GB |
| customers | 500 MB |
| transactions | 300 MB |
- WAL（トランザクションログ）の監視。
アクティブなDBだと、トランザクションログがすぐに膨らむことも。サイズはこうやって調べられる：
SELECT pg_size_pretty(pg_xlog_location_diff(pg_current_wal_lsn(), '0/0')) AS wal_size;
まとめ
これでPostgreSQLのシステムメトリクスを監視するためのツールと知識が手に入ったね：
- CPU負荷の監視には
htopやpg_stat_activityを使おう。 - メモリの最適利用には
shared_buffersやwork_memのパラメータを調整しよう。 - DBやテーブル、インデックスのサイズを定期的にチェックして、ディスク不足を防ごう。
こういうスキルがあれば、予期せぬトラブルを避けて、PostgreSQLサーバーを最高の状態に保てるよ。サーバーのことを考えるときは、リソースをちゃんと管理すれば、君のプロダクトはユーザーにとって一番人気になるってことを忘れないで！
GO TO FULL VERSION