こんにちは！データベースの裏側でうごめくクエリやトランザクションの気配を感じ取れるようになると、エンジニアとしての視界が一気に広がります。
今回は、PostgreSQLを運用する上で絶対に避けて通れない「パフォーマンス監視とチューニング」の第一歩として、公式管理ツール「pgAdmin」のダッシュボード機能を取り上げます。
「重いクエリがあるみたいだけど、どこを見ればいいかわからない……」
「ロック競合でアプリがフリーズしたけれど、原因のセッションをどう特定すればいいの？」
そんな悩みを抱えていませんか？ 大規模な監視システム（PrometheusやGrafanaなど）を導入する前段階として、実はpgAdminのダッシュボードを覗くだけで、現場で起きているボトルネックの8割は特定できます。
これをマスターすれば、毎日のDB運用やパフォーマンス調査が劇的に楽になりますよ。さあ、一緒にデータベースの「心音」を聞きに行きましょう！
—
1. pgAdminとは？その役割と真価
pgAdminは、PostgreSQLの公式Webベース（およびデスクトップ版）統合管理ツールです。テーブルの作成やデータの参照だけでなく、サーバーの内部状態を可視化する強力なGUIを備えています。
多くの初心者は「SQLを書くためのエディタ」としてしか使っていませんが、実は「リアルタイムの健康診断ツール」としての能力こそが本質です。黒い画面（CUI）で複雑なシステムビューを叩かなくても、直感的なグラフやテーブルでPostgreSQLの「いま」を教えてくれます。
—
2. 導入と基礎セットアップ：まずはココを確認！
すでにpgAdminがインストールされている前提で話を進めますが、ダッシュボード機能（特にリアルタイムのパフォーマンス統計）を最大限に活かすためには、「サーバー接続のポーリング間隔」を正しく設定しておく必要があります。
接続プロパティの最適化
1. pgAdminの左側ツリービューから、監視したいPostgreSQLサーバーを右クリックし、「プロパティ (Properties)」を開きます。
2. 「接続 (Connection)」タブを確認します。
3. 接続情報（ホスト名、ポート、ユーザー名、パスワード）が正しく入力されていることを確認し、保存します。
ダッシュボードの表示方法
1. 左側ツリービューでサーバー名（または特定のデータベース）をクリックします。
2. メイン画面にいくつかのタブが表示されます。その中にある「ダッシュボード (Dashboard)」タブを選択してください。
これだけで、CPU使用率、セッション数、トランザクションの単位時間あたりの処理数（TPS）などが美しくグラフィカルに表示されます。
—
3. ダッシュボードの読み方：3大チェックポイント
ここからが本題です。pgAdminのダッシュボードに現れる無数のグラフや数値の中から、現場のプロが最初に見るべき3つの重要ポイントを解説します。
① セッション管理（Active Sessions）
データベースへの「同時接続数」と「その内訳」を把握するグラフです。
- どこを見るか: 「Active（アクティブにクエリを実行中）」と「Idle（接続はしているが何もしていない）」の比率です。
- チューニングのコツ:
- `max_connections`（最大接続数）の制限に近づいていませんか？
- アプリ側でコネクションプールが適切に機能していない場合、`Idle in transaction（トランザクション中のまま放置されたアイドル状態）`のセッションが溜まり、リソースを圧迫します。ここが増えている場合、アプリケーション側のコード（トランザクションの閉じ忘れ）に原因があります。
② ロック状況（Locks & Lock Conflicts）
PostgreSQLは行レベルやテーブルレベルでロックをかけますが、これが競合するとアプリケーションが「固まった」ようになります。
- どこを見るか: ダッシュボード内の「Locks」ウィジェット、またはより詳細な「Sessions」タブです。
- 簡易チューニングのコツ:
- どのクエリがどのクエリをブロック（待機）させているのかを特定します。
- もし悪質なロック競合を見つけたら、pgAdminのセッション一覧から該当するプロセスを右クリックし、「SQLをキャンセル (Cancel Query)」または「接続を切断 (Terminate Session)」して緊急回避が可能です（本番環境では慎重に行ってください！）。
③ CPU・メモリ使用率とディスクI/O
OSレベル、あるいはPostgreSQLプロセスがどれだけリソースを消費しているかの指標です。
- どこを見るか: 「Server Activity」や「IO Stats」のグラフ。
- 簡易チューニングのコツ:
- CPUが常に100%に近い場合: インデックスが効いていないフルスキャン（Seq Scan）が大量発生している可能性があります。`EXPLAIN ANALYZE`を使ってクエリを見直しましょう。
- ディスクI/O（Read/Write）が高い場合: `shared_buffers`（メモリキャッシュ）のサイズが小さすぎて、メモリに乗り切らないデータが頻繁にストレージから読み出されているサインです。メモリ割り当ての見直しが必要です。
—
4. 精度高い「HelloWorld的な動作確認」：あえて重いクエリを流して観察する
ダッシュボードの見方がわかったところで、実際に負荷をかけたときのグラフの変動を自分の目で確認してみましょう。百聞は一見に如かずです。
以下の手順で「あえて少し重い処理」を流し、ダッシュボードがどう反応するかをライブで観察します。
手順1: クエリツールの起動
pgAdminのツールバーから「SQL」アイコン（Query Tool）を開きます。
手順2: 意図的な負荷クエリの実行
以下のSQLをエディタに貼り付けて実行してください。これは、ダミーの大量データを生成してCPUとディスクに負荷をかける疑似的なテストクエリです（安全な範囲のデータ量にしています）。
— 【動作確認用】意図的な高負荷・大容量データ生成クエリ
— 100万行のダミーデータを生成し、結合処理（クロスジョブ）を行うことで
— 一時的にCPUとメモリ、セッションの動きを活発化させます。
SELECT
gs.id AS id_1,
g2.id AS id_2,
MD5(gs.id::text) AS hash_val
INTO TEMP TABLE temp_heavy_test
FROM generate_series(1, 5000) gs
CROSS JOIN generate_series(1, 200) g2;
— テーブルを削除してクリーンアップ
DROP TABLE temp_heavy_test;
手順3: ダッシュボードのライブ観察
SQLを実行した瞬間に、別タブで開いておいた「ダッシュボード」を確認してください。
- Active Sessionsの数が跳ね上がりましたか？
- CPU Usageのグラフがグッと上に突き抜けましたか？
- Transactions (TPS) のグラフに変化はありましたか？
この「負荷とグラフの連動」を自分の手で体感することが、DBチューニングのセンスを養う最速の近道です。
—
おわりに
データベースのパフォーマンス監視と聞くと、なんだか難解で専門的なツールが必要なイメージがあったかもしれません。しかし、手元にある「pgAdmin」のダッシュボードを適切に眺め、セッションやロック、リソースの相関関係に意識を向けるだけで、システムで何が起きているのかが手に取るようにわかるようになります。
「アプリが遅い」と感じたら、まずはパニックにならずにpgAdminを開き、ダッシュボードのグラフを深呼吸しながら眺めてみてください。データベースは、必ず今の状態を正確に語りかけてくれますよ。
日々の開発・運用ライフが、今回の知見によってより快適なものになることを願っています！