データの海を航海する船長になったつもりで考えてみて。船をただ進ませるだけじゃなくて、長いクエリという氷山にぶつからないようにしたいし、突然のロックの嵐に巻き込まれたくないし、接続の過負荷で沈没したくもないよね。データベースの監視は、レーダーであり、気圧計であり、魚群探知機みたいなもの。氷山や嵐、パニックを避けるための必須アイテムだよ。
なんで、どうやってデータベースを監視するの？
監視をちゃんとやると、DBが安定して動くし、問題の兆候も早めにキャッチできる。たとえば、サービスがいきなり落ちる代わりに「おい、ここでクエリがもう30秒も動いてるぞ、なんか変だぞ」って早めにアラートが来る感じ。どこが詰まってるか、誰がロックを持ってるか、どのタイミングでリソース不足になりそうか、事前に分かるんだ。
こんなポイントに注目しよう：
クエリとトランザクションのアクティビティ。 クエリの流れを、交差点の交通整理みたいに見張ろう。どのSQLコマンドが他を遅くしてる？誰が一番DBを重くしてる？こういう答えが分かれば、焦らずパニックにならずに最適化できるよ。
リソースの使い方。 CPU、メモリ、ディスク容量は、船の燃料や船体みたいなもの。どれかが「漏れてる」か、オーバーロードしてたら、船全体が止まっちゃう。監視でどこが重いか分かるから、負荷を分散できるよ。
クエリのパフォーマンス。 一部のSQLクエリは、わがままな乗客みたいなもんで、やたらリソースを食って他を遅くしたり、ずっと文句言ってたりする。監視で特に「大食い」なやつが分かるから、インデックスを貼ったり、書き直したり、置き換えたりできる。
ロックとコンフリクト。 時々クエリ同士がバッティングすることもある。誰かがリソースを持ってて、他が待ってる状態。ドアを片方が引っ張って、もう片方が逆に引っ張ってる感じ。こういうロックを監視しておけば、タイミングよく介入してストレスを減らせるよ。
いい監視は、単に「DBが生きてるよ」って教えてくれるだけじゃない。どこでトラブルが起きそうかヒントをくれて、問題が現実になる前に直すチャンスをくれるんだ。
PostgreSQL監視のキーメトリクス
DBの状態をちゃんと把握するには、どこを見ればいいか知っておく必要がある。これらのメトリクスは、DBの「脈拍」と「血圧」みたいなもの。主なパラメータはこれ：
アクティブな接続数。
今何人が接続してる？無茶なクエリでDBを壊そうとしてるやつはいない？例えば、
pg_stat_activity（これは次の講義で話すよ）で今のアクティビティが見える。クエリの実行時間。
どのクエリが一番速い？逆に、どのクエリが「もう引退してもいいんじゃない？」ってくらい遅い？
インデックスの利用状況。
インデックスがあるのに使われてなかったら、何かおかしいよね。これは
pg_stat_user_indexesでチェックできる。ロックとコンフリクトのレベル。
「Deadlocks」（相互ロック）を防ぐためによく使われる。
CPU負荷とメモリ使用量。
例えば、PostgreSQLがサーバーのリソースをどれだけ「食ってる」か？
実際どうやるの？
実際の例を見てみよう。特定のDBのサイズを知りたいときに使えるシンプルなクエリがこれ：
SELECT pg_size_pretty(pg_database_size('kimi_no_db_namae')) AS database_size;
このシンプルなクエリは、DBのサイズを分かりやすいフォーマットで返してくれる。たとえば、243 MBとか1.2 GBみたいな感じ。最近どれくらいDBが大きくなったかサクッと知りたいときに便利だよ。
全部のDBサイズを一気に見たいなら、いちいち名前を指定しなくても、こんなクエリが使える：
SELECT datname, pg_size_pretty(pg_database_size(datname)) AS size
FROM pg_database;
これならサーバー上の全DBのサイズが一覧で見れる。ディスク使用量を見張ってる管理者には超便利。「大食い」なDBを早めに見つけて、ホスティングから「もうすぐ容量切れるよ」ってメールが来る前に対処できるよ。
GO TO FULL VERSION