【入門編】 log_min_duration_statement – PostgreSQL

「あれ、なんか今日遅くない?」を解決する!PostgreSQLの健康診断術

こんにちは!データベースエンジニアとして日々コードと格闘している私ですが、今日は皆さんに、PostgreSQLと仲良くなるための「最初の一歩」についてお話ししようと思います。

Webアプリを運営していると、たまに「なんか最近、画面の切り替わりがモタつくんだよね」なんて相談を受けること、ありませんか? ユーザーからすると、たった1〜2秒の遅延でも結構なストレスです。

そんな時、私たちエンジニアが最初に疑うのが「データベースのどこかで、迷子になっているクエリがいるんじゃないか?」という疑惑です。今日は、そんな「遅いクエリ」を犯人特定するための秘密兵器、『log_min_duration_statement』について解説しますね。

—

「行列」で例えると分かりやすいかも?

想像してみてください。あなたは今、大人気のラーメン屋さんの店長さんです。

いつもはサクサク回転しているはずなのに、なぜか今日はお店の入り口に行列ができています。お客さんが「まだかな?」とソワソワしている状態ですね。

さて、この状況で「どの注文が原因で詰まっているのか」を突き止めるにはどうしますか?
厨房を覗いて、「お、この餃子は焼き上がるのに10分もかかってるぞ!」とか「この炒飯、作るのに時間がかかりすぎじゃない?」ということに気づく必要がありますよね。

PostgreSQLにおける`log_min_duration_statement`は、まさに「一定時間以上かかっている注文(クエリ)だけを、調理日誌(ログ)に書き残す」という設定なんです。

設定するのはこれだけ!

難しく考えないでくださいね。設定ファイル(`postgresql.conf`)に、たった一行書き加えるだけです。

log_min_duration_statement = 500

これは、「500ミリ秒(つまり0.5秒)以上かかったクエリは、全部ログに残してね!」という命令です。

これを入れておくと、もし「あ、今のクエリ遅かったな」という場面があったとき、サーバーのログファイルを開けば、「どのクエリが、何ミリ秒かかったのか」がバッチリ記録されているんです。これでもう、勘に頼って闇雲にコードを修正する必要はありません!

運用する時のちょっとしたコツ

この設定、すごく便利なんですけど、一つだけ注意点があります。

あまりに短い時間(例えば10ミリ秒とか)に設定してしまうと、ログファイルが「遅いクエリ」の報告書でパンパンに埋め尽くされてしまいます。これでは、本当に大事な「重いクエリ」を見つけるのが逆に大変になってしまいますよね。

  • 最初は長めに設定する: まずは `1000`(1秒)くらいから始めて、「特に遅いものだけ」を拾い上げるのがおすすめです。
  • 様子を見ながら調整: 余裕が出てきたら少しずつ数値を下げて、チューニングの解像度を上げていきましょう。

最後に:データベースは、あなたの味方です

「クエリをログに残す」なんて言うと、なんだか監視されているみたいで怖い……なんて思う方もいるかもしれません。でも、これはデータベースをいじめるためじゃなくて、データベースがどこで苦しんでいるのかを知るための「対話」なんです。

「最近、うちのDBちょっと疲れ気味かな?」と思ったら、ぜひこの設定を試してみてください。きっと、今まで見えていなかった「改善のヒント」が見えてくるはずですよ。

もし設定方法でつまづいたり、「これってどう解釈すればいいの?」という疑問が出てきたら、いつでも相談してくださいね。皆さんのデータベースライフが、もっと快適になりますように!

それでは、また次回の記事でお会いしましょう!

コメント

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