PostgreSQL チューニング, 今年の年賀状, ニュースステーション

PostgreSQL チューニング

あんまり IO が速くないマシンで、とにかく bulk insert の性能を稼ぐにはどうするか、というチューニング。
bulk insert のみ、という条件だとなんとなく shared_buffers や wal_buffers といったパラメータはあまり関係がないようで、wal_sync_method と checkpoint_segments あたりが肝な模様。いろいろと試行錯誤中です¹。あ、もちろんデータファイル領域 ($PGDATA/base) とログ領域 ($PGDATA/pg_xlog) は異なる物理ディスク上に配置してあります。
wal_sync_method ですが、Linux 2.4 で普通の SCSI ディスクだと fsync と fdatasync がほとんど同じ、open_sync はそれの２倍くらい遅い、という感じのよう (open_datasync は使えませんでした)。確か PC Solaris だと open_datasync が一番速かったような気がするんだけど…²。 後者の checkpoint_segments について。Oracle なんかだと checkpoint 間隔があんまり短くなり過ぎないように調整するのがセオリーだけど、PostgreSQL で checkpoint_segments をデカくしてチェックポイント間隔を広げると、いざチェックポイントが発生した時にかなり長い間ロックアップ状態になってしまう。確かに単にスループットで比較すれば間隔を広げた方が良いんだけど、長時間アプリケーションが pause してしまうのは致命的な場合もあるよなぁ。この問題は普通どうやってチューニングするんだろう？
とかなんとかいろいろ調べている間に、PostgreSQL の ML にこんなメールが！つまり、bulk insert 中に他のテーブルをまとめて引き抜く (大量の sequential scan 発生) ような処理は 7.4 ではツライかもしれない、ってことか…。もう少しいろいろテストしてみよう。
そういや pgbench の initialize 時の tuple 生成の速度を調べたら、80000tuples/sec 以上の速度で insert 出来てるじゃん！…と思ってソースを読んでみたところ、単に insert してるわけじゃなくて copy コマンドを使っているのですね。この手をアプリケーションで使う、ってのはアリなのかな…。

今年の年賀状

は、こんな感じでした。親が写っていない、いわゆる「嫌われる」年賀状ですが、コンセプト³のためにしょうがなかったのだ、ということにしておいてください。親ばかだ〜＞俺。

ニュースステーション

今日は久々に真理さんいじめの珍味のコーナー (食の快楽) があった。森永さんと真理さんは何気にいいコンビだ…。

コメント

TrackBack (Fri, 21 Jan 2005 20:28:13)

http://host4.headoffice.jicoo.co.jp/wiki/index.php?DB%2FPostgreSQL
PukiWiki/TrackBack 0.1
DB/PostgreSQL
DB PostgreSQL Info News from PostgreSQL site RSS Headline [Tips]チューニング [Tips]PostgreSQL チューニング 編集中 Links PostgreSQL † 老舗のOracle型DB ISO SQLに近い実装 ↑ Info † Postg...