[hackers-jp: 210] Re: [Fwd: Re: [HACKERS] [PATCHES] O_DIRECT for WAL writes]

[Hiroki Kataoka]

片岡です。

ITAGAKI Takahiro wrote:
> fsync を上回る性能が出たでしょうか？　もしそうなら意外です。
> Gather Write は、open_sync 時のまずい動作を、
> fsync 相当に修正するだけというつもりでした。

　「大きく」というのはちょっと大げさだったかもしれません。ですが、スルー
プットは確実に向上しています。まとめ書きによって多少なりとも効率がよくな
るのでしょうか。下記はちょっと現実離れしたテストですが、参考までに。

1レコード64バイト 10万件のINSERT：
    fsync         25.6s   ↓     ↓
    open_sync     23.4s  +9.5%         ↓
    open_sync+gw  22.1s        +15.6%  +5.6%

1レコード1Kバイト 10万件のUPDATE：
    fsync         30.5s   ↓     ↓
    open_sync     28.2s  +8.1%         ↓
    open_sync+gw  26.3s        +15.9%  +7.2%

　ただ、板垣さんの想定と違うと思われるところは、こちらのテスト環境のHDD
がライトバックになっている点です。なので、素のままのopen_syncでもfsyncよ
り速かったりします（Gather Writeをつけるとさらに速くなる）。

>>　あとは、open_sync（open_datasync）指定時のO_DIRECTを簡単に無効にできれ
>>ば完璧なんですが…今はソースを書き換えないとならないので。

> やっぱり分けたほうが良かったでしょうか？
> OSのバグだからといって、知らん振りはできませんし……。

　分けてあるに越したことはないですが、そういう場合にはfsyncで我慢する、
という結論もありかもしれません。それよりも、そういう壊れた環境に
PostgreSQLをインストールした結果、自動的に選択された設定がopen_*syncだっ
たりしたらちょっと厳しいかもしれません。そういう環境は今のところ存在しな
いかもしれませんが。

> 2.4+ext3+O_DIRECT の件は、まさにこの事象だと思いますので、
> 本家にもご報告されてはいかがでしょうか？

　報告しても良いですが、やり方を間違えるとTomのO_DIRECT不要説の後押しを
してしまう可能性があるので、どうしたものか…。

-- 
Hiroki Kataoka <kataoka ＠ interwiz.jp>