【実務・中級編】 track_activities – PostgreSQL

「お疲れ様です。最近、PostgreSQLのパフォーマンスチューニングで頭を抱えてるって聞いたけど、どうだい? 順調?」

現場でPostgreSQLを触っていると、どうしても避けて通れないのが「今、この瞬間に何が起きているか」を把握することだよね。今日は、そんな時にまず最初に見るべき、だけど意外と深掘りされていない`track_activities`という設定について、実務的な話をしようと思う。

—

`track_activities` は「PostgreSQLの心拍計」だ

PostgreSQLには、システムの状態を可視化するための統計情報収集機能がある。その中でも、今走っているクエリを監視するのが`pg_stat_activity`ビューだ。

このビューが正常に機能するためには、`postgresql.conf`で`track_activities = on`になっている必要がある。

「いや、そんなのデフォルトでONだし、わざわざ意識しなくていいでしょ?」なんて思ったら大間違い。大規模なトラフィックを捌くデータベースだと、この設定がOFFになっているだけで、トラブルシューティングの初動で「何も見えない暗闇」に放り出されることになる。

なぜこれが重要なのか?

パフォーマンスが急激に悪化した時、僕らが最初にやるのは「今、何が重いんだ?」を確認することだよね。

SELECT pid, usename, state, query, wait_event_type, query_start
FROM pg_stat_activity
WHERE state != ‘idle’;

もし`track_activities`がOFFだったら、`query`カラムはNULLになるし、`query_start`も更新されない。つまり、「誰かが何か重いことをしているのは分かるけど、それが何なのか分からない」という、エンジニアにとって最悪の状況に陥るんだ。

—

現場で役立つ活用テクニック

単に「ONにしておけばいい」だけじゃなくて、実務ではもう一歩踏み込んだ使い方をする必要がある。

1. 長時間クエリの炙り出し

`track_activities`が効いていれば、`query_start`から現在時刻を引くことで、「どれくらいハマっているか」が丸見えになる。

SELECT pid, now() – query_start AS duration, query
FROM pg_stat_activity
WHERE state = ‘active’
AND now() – query_start > interval ‘5 seconds’;

これ、リリース直後のバグ調査で何度救われたことか。インデックスが効いていないスキャンが走った時、これで秒殺できる。

2. ロック待ちの特定

DBが急に重くなる原因の8割はロック待ちだ。`wait_event_type`を確認して、何で止まっているかを把握する癖をつけよう。

SELECT pid, wait_event_type, wait_event, query
FROM pg_stat_activity
WHERE wait_event_type IS NOT NULL;

`Lock`や`LWLock`が頻発していたら、アプリケーション側のトランザクション設計を見直すサインだね。

—

注意点:オーバーヘッドを過剰に恐れるな

たまに「監視設定をONにすると負荷が上がるから」と言って、必要最低限しか設定しない現場を見る。でも、`track_activities`に関しては、そこまで神経質になる必要はないよ。

確かに統計情報の更新にはCPUリソースを多少消費するけれど、「何が起きているか分からないままサーバーがダウンする」ことの損失に比べたら、誤差みたいなものだ。

ただし、一つだけ気をつけるなら、`track_activity_query_size`の設定値だ。デフォルト(通常1024バイト)だと、複雑なJOINクエリや大量のINSERT文を流した時にクエリ文字列が途中で切れてしまうことがある。解析したいクエリが途中で切れていたら意味がないから、必要に応じてここを調整するのはアリだね。

—

最後に:先輩からのアドバイス

「監視」っていうのは、何かあった時のためだけにあるんじゃない。「平常時の正常な状態を知っておくため」にあるんだよ。

何も起きていない時に`pg_stat_activity`を眺めて、「あ、このアプリはいつもこういうクエリを吐いているんだな」という感覚を養っておいてほしい。そうすれば、いざ障害が起きた時に「いつもと違う動き」に一瞬で気づけるようになる。

`track_activities`は、データベースという巨大な船の「計器盤」だ。まずはここがしっかり動いているか、改めて確認してみよう。

もし設定で迷ったり、解析の切り分けで詰まったら、いつでも聞きに来てくれ。一緒にログを読み解こう。

それじゃ、また!

コメント

タイトルとURLをコピーしました