【実務・中級編】 track_io_timing – PostgreSQL

やあ。今日もデータベースと格闘してる?

PostgreSQLを使っていて「なんだかクエリが遅いな」と感じたとき、真っ先にどこを見る? `EXPLAIN ANALYZE` を叩いて、実行計画を眺めるよね。でも、たまに「実行計画は悪くないはずなのに、なぜか時間がかかっている」という、モヤモヤするケースに遭遇しないかな。

そんなとき、多くのエンジニアが最初に見落としがちな、でも実は最強の武器があるんだ。それが `track_io_timing` という設定だ。今日は、こいつを使いこなして「見えないボトルネック」を可視化する方法について話そうと思う。

—

なぜ `track_io_timing` が必要なのか

デフォルトのPostgreSQLでは、実はI/Oにかかった時間の計測はオフになっている。なぜかって? それは、I/Oの計測自体がわずかながらオーバーヘッドになるからだ。高負荷な環境だと、その微々たるコストすら惜しいという判断なんだろうね。

でも、パフォーマンスチューニングの現場において、「どこで時間が溶けているのか」が分からないことほど怖いものはない。

  • CPUがボトルネックなのか?
  • ロック待ちで止まっているのか?
  • それとも、ディスクからの読み込み(I/O)で待たされているのか?

`track_io_timing` を有効にすると、`pg_stat_database` や `pg_stat_statements` などの統計情報に、I/O待ちの時間が記録されるようになる。これがあるのとないのとでは、原因究明のスピードが雲泥の差だよ。

—

早速設定してみよう

設定は拍子抜けするほど簡単だ。`postgresql.conf` を開いて、以下のパラメータを探してみてほしい。

postgresql.conf
track_io_timing = on

変更したら、再読み込み(`pg_ctl reload` または `SELECT pg_reload_conf();`)を忘れずに。これだけで準備完了だ。ちなみに、この設定はオンラインで変更できるから、本番環境で急に調査が必要になったときでも安心だよ。

—

実践:クエリの「言い訳」を聞き出す

`track_io_timing` が真価を発揮するのは、`pg_stat_statements` と組み合わせたときだ。例えば、「最近このクエリ、急に遅くなった気がするんだよな……」というクエリを特定してみよう。

SELECT
query,
calls,
total_exec_time,
blk_read_time,
blk_write_time
FROM pg_stat_statements
ORDER BY blk_read_time DESC
LIMIT 5;

ここで注目してほしいのが `blk_read_time` だ。これが「ディスクからデータを読み込むために待機した合計時間」になる。

もし `total_exec_time`(実行時間の合計)に対して `blk_read_time` の割合が高ければ、それはクエリのロジックが悪いんじゃなくて、「物理ディスクが悲鳴を上げている」か「メモリ(shared_buffers)に載りきっていない」というサインだ。

こうなれば、チューニングの方向性が一発で決まる。

  • インデックスを貼ってアクセスするブロック数を減らす(論理的な解決)
  • shared_buffers を増やす(ハードウェアリソースの解決)
  • SSDのIOPSを見直す(インフラの解決)

闇雲にSQLを書き換えても解決しない問題が、これだけでクリアになるんだ。

—

注意点:過信は禁物

一つだけ、先輩として釘を刺しておこう。この数値を鵜呑みにしすぎるのも危険だ。

`track_io_timing` は、あくまで「OSやストレージにI/Oリクエストを出してから戻ってくるまでの時間」を測っているに過ぎない。もしクラウド環境(AWSのRDSなど)を使っているなら、ストレージのバーストクレジットが枯渇しているとか、ネットワーク越しにストレージをマウントしていることによる遅延も、この数値に混ざってくる。

だから、「I/O時間が長い=PostgreSQLの設定が悪い」と決めつけず、OS側のメトリクス(iostatの `%util` とか)と見比べる癖をつけてほしい。

—

まとめ

最後に大事なことを一つだけ。

「計測できないものは改善できない」。これはエンジニアの格言だ。`track_io_timing` を有効にしておくことは、いわばデータベースという真っ暗なトンネルに懐中電灯を持って入るようなものだよ。

もし君がまだこの設定をオフにしているなら、今すぐオンにすることをおすすめするよ。そして、次にパフォーマンスの問題にぶつかったとき、この数字が君を導いてくれるはずだ。

さて、今日はこの辺で。また何か困ったことがあったら、いつでも聞きに来てくれ。君のデータベースが、今日も健やかであることを祈っているよ。

コメント

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