2006.09.21 Thursday
VACUUM ANALYZE って大事だよね
データベースの応答が遅い。えぇ, 良くあることです。
大抵の場合は SQL が腐ってるパターンですが, 現象を聞くとどうやらタイミングによって応答が速かったり遅かったりするらしい。
どうもおかしいということで, 問題の DBサーバを調査してみました。
大抵の場合は SQL が腐ってるパターンですが, 現象を聞くとどうやらタイミングによって応答が速かったり遅かったりするらしい。
どうもおかしいということで, 問題の DBサーバを調査してみました。
DBサーバは PostgreSQL 7.4.x で pgpool を使って 2台でレプリケーションして負荷分散する構成。
pgpool 経由で問題のあるクエリを投げると確かに遅い。
EXPLAIN ANALYZE すると, しばらくして kind mismatch のエラーが返って来る始末。
不整合を疑って, マスタとスレーブのテーブル内容を比較するも問題なし。
問題の SQL自体はもう手のつけようが無いくらい複雑なのですが, JOIN しているテーブルのデータ数自体は 2000件にも満たない。
マシンスペックを考えるとこんなに遅くなるはずが無いのだが･･･うーむ？
とりあえずマスタに接続してクエリを実行すると瞬時に応答が。
スレーブに接続してクエリを実行するとやたらと時間がかかっている。
これか！Σ(ﾟДﾟ
スレーブで EXPLAIN ANALYZE してみると, 見積もりコストと実際の実行時間に大きくずれが。
このパターンは･･･。
予想通り VACUUM のバッチ処理がこけていて, スレーブだけ VACUUM ANALYZE されていませんでした。
そのせいで, 現状の状態と統計情報が大きくずれていて, オプティマイザが適切な実行計画を立てられなかったというオチ。
PostgreSQL の運用の際にはちゃんと VACUUM ANALYZE を忘れずに, という教訓。
常識といえば常識なんですが, PostgreSQL さわりたてホヤホヤの人は忘れがちなので注意。
VACUUM のログは定期的にメールなどで送るようにして, FSM が足りているかどうか等を確認できるようにもしておきましょう。
pgpool 経由で問題のあるクエリを投げると確かに遅い。
EXPLAIN ANALYZE すると, しばらくして kind mismatch のエラーが返って来る始末。
不整合を疑って, マスタとスレーブのテーブル内容を比較するも問題なし。
問題の SQL自体はもう手のつけようが無いくらい複雑なのですが, JOIN しているテーブルのデータ数自体は 2000件にも満たない。
マシンスペックを考えるとこんなに遅くなるはずが無いのだが･･･うーむ？
とりあえずマスタに接続してクエリを実行すると瞬時に応答が。
スレーブに接続してクエリを実行するとやたらと時間がかかっている。
これか！Σ(ﾟДﾟ
スレーブで EXPLAIN ANALYZE してみると, 見積もりコストと実際の実行時間に大きくずれが。
このパターンは･･･。
予想通り VACUUM のバッチ処理がこけていて, スレーブだけ VACUUM ANALYZE されていませんでした。
そのせいで, 現状の状態と統計情報が大きくずれていて, オプティマイザが適切な実行計画を立てられなかったというオチ。
PostgreSQL の運用の際にはちゃんと VACUUM ANALYZE を忘れずに, という教訓。
常識といえば常識なんですが, PostgreSQL さわりたてホヤホヤの人は忘れがちなので注意。
VACUUM のログは定期的にメールなどで送るようにして, FSM が足りているかどうか等を確認できるようにもしておきましょう。
Comments