postgresqlのパフォーマンスを向上させるために、WALログ($PGDATA/pg_xlog)を tmpfs に載せようかと考えているのですが、実際、そのようにしたことある方はいらっしゃいますでしょうか?その場合、実際どのくらい性能向上したでしょうか?


また、WALログを tmpfs にのっけた場合のリスクはどのようなものが考えられるでしょうか?

テーブル全体もしくは一部を tmpfs に載せた経験がある方がいらっしゃれば、その場合の性能向上とリスクも教えていただければ幸いです。

回答の条件
  • 1人2回まで
  • 登録:2008/02/06 15:09:35
  • 終了:2008/02/13 15:10:02

回答(1件)

id:b-wind No.1

b-wind回答回数3344ベストアンサー獲得回数4402008/02/07 03:12:44

ポイント60pt

実際どのくらい性能向上したでしょうか

まったくと言っていいほど変わらなかったなぁ。あくまで pgbench での計測ですが。


WAL導入以前では、書き込み中にクラッシュした場合に次のようなことが起こる可能性がありました。

(中略)

部分的にしかデータページが書かれていないために、完全にテーブルやインデックスのページの内容が壊れてしまう

WAL の目的の一番大きいのがここで、かつ tmpfs が再起動すると消えてしまうファイルシステムであることを考えると、

  • 書き込み中の電源断などクラッシュと再起動が起こった状況で、データの破損の可能性がある

ということでしょう。


レプリケーションでもして、データ破損が問題ない状況でもない限りやめた方がいいと思います。

id:mhxng366

なるほど、WAL導入以前の非同期書込みと同じような状況で、安全性を犠牲にする代わりにパフォーマンスをとるという形になるということですね。

そして、そのパフォーマンス(性能向上)すらベンチマークで見る限りあやしいと・・・・

データ破損については気になっていました。

メモリファイルシステム上にチェックポイントレコードを置くのがいいのか?

データ破損した場合、整合性をとる方法があるのかなどです。

2008/02/07 08:54:30
  • id:b-wind
    >メモリファイルシステム上にチェックポイントレコードを置くのがいいのか?
    通常良くないです。
    >データ破損した場合、整合性をとる方法があるのかなどです。
    繰り返しますが、「整合性をとる方法」が WAL の導入そのものです。
  • id:mhxng366
    b-windさん、回答ありがとうございます。

    >通常良くないです。

    ですよね。

    この件は、メリットが見えないので見送ることにしました。
    別の方法を検討します。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません