[postgresql] ロードアベレージが高すぎると感じたらどうするか？(2008/07/25)

　ロードアベレージが3桁になろうとしているのだが、落ち着いてどう対処すべきか考えている時のメモ。とりあえずグーグル先生に聞いてみたところ、

マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
http://d.hatena.ne.jp/naoya/20070518/1179492085

こちらのエントリーが参考になるようなので真面目に読んでみる。

• top や sar がデフォルトで示すCPU使用率はCPU数(コア数)で割り算をしている。各CPUごとに値を保持している。
• ロードアベレージは割り算をしていない。各CPU(ランキュー)ごとに値を保持するのではなく、システム全体で一つ。
• 4CPU ならロードアベレージ 4.00 まで OK、は鵜呑みにしないほうがよさそう。状況によって異なるのでその他の指標も使って細かく統計を分析したほうがよい。
  • nr_running > 1 のときはロードバランスが適切に働く。そのため 4CPU なら 4.00 で割れ、というのは負荷があるときはそれなりに正しい。
• ランキューに溜まってるタスク数が CPU 毎に見れたらいいのだけど、現時点のカーネルの実装では難しい。(全体のは sar -q で見れます。)

途中でまとめがあった↑。どうやら、ロードアベレージが100になっても、CPUコアが100あるなら気にしなくて良いことがわかった^^。CPUコアいくつだったかな。クアッドｘ4だったかしら。だとすると16なのか？

　とまぁ、ロードアベレージのことはここまで。[追記]読み返してみたらロードアベレージが高すぎるときにどうするか？に対する答えをまとめていないことに気づく。しかしまとまってもいないので書きようが無いのだ。やりながらどう対処したのかいつか書きたいものである。それとサーバーはデュアルコアの2CPUだったので4ということに。100だとすると1CPUあたり25である。これは厳しい。

　naoyaのはてなダイアリーを徘徊していたら、

Linux のページキャッシュ - naoyaのはてなダイアリー
http://d.hatena.ne.jp/naoya/20070521/1179754203

なるエントリーもなかなか興味深い。参照のみのテーブルが極めて少ないので、パフォーマンスの向上にはきかないと思う。

　そういえば、なんとなくふと気になったのだが、postgresql8.3で実装されたHOTの仕組み。VACUUMいらずの運用に期待を抱かせるものだが、ORマッパーの実装と相性が悪いのでは？よく、ORマッパーはアップデート処理する際に変更する必要の無いカラム（フィールド）に対してもupdateをかける。

　そうすると、「値が変更されていなくても、DBが上書き処理して、HOTのメリットを活かせない！」と思ったのだが、真相はいかに。