Linuxでは多くのファイルシステムがあり、現在も様々なものが開発中です。
メジャーなものとしてext2、ext3がありますが、現在ext4が主流になろうとしています。また、oracleが開発したBtrfs(B-tree file system)などのような、SSDへの最適化やCOW(Copy on Write)など次世代のファイルシステムが沢山あります。
そこで、あまり最新のものは今後やるとして、昔からあるファイルシステムと今のファイルシステムでどの程度パフォーマンスに差があるのか検証してみます。
* 本当はBtrfsも検証したかったのですが、SSDが不調なのとDIRECT I/Oが未サポートだったので断念しました
ext2からext3がLinuxの主流になったとき、ext3のジャーナリング機能を嫌い、Oracle構築でxfsを使う方も多かったのではないでしょうか?何せ、xfsはメタデータのみジャーナリングを行い、実データに関しては基本知らんぷりという仕様だからです。そんな中途半端?なジャーナリングを備えたファイルシステムがなぜ、好まれるのか?
答えは簡単です。Oracleにとって実データのジャーナルは必要ないからです。OracleはデータベースのファイルをO_SYNCオプションを付けて、オープンします。それは、OSのファイルキャッシュが危ないことを知っているからです。Oracleが「書いた!」と思っても、実はファイルキャッシュにしか書かれておらず、実際のファイルには「書かれていない!」こともあり得るわけです。これを確実に「書いた!」もしくは「失敗した!」とするため(白黒はっきりさせるため)にO_SYNCオプションを付けてオープンしているわけです。
とりあえず、上記のように、ファイルシステムは沢山あって、ジャーナリングなど高機能を提供するものも多い。ただ、そのような高機能が不必要な場合もあるわけで、システムによって、特性を見極めてファイルシステムを選択する必要もあるかも知れない。というわけで、今回はファイルシステムの性能を測定してみました。
1. ext4(writeback)
2. ext4(ordered)
3. ext3(writeback)
4. ext3(ordered)
5. xfs
6. ext2
6パターンのパフォーマンスを比較してみます。前回と同じ測定方法です。
結果は、xfsが大健闘、甲乙つけがたい感じで、ext4のパフォーマンスが素晴らしい。逆にext3は、かなり苦戦を強いられている。xfsやext4はエクステントでブロックを確保するが、これが、読み込み時に有利に働くと思われます。
ただ、これを書いていて思ったのですが、今時みんなASMですかね。。。
&chxt=x,y&chs=400x200&chg=0,10.50,1,5&chco=0092B9,86AD00,F2B705,BC3603,80C65A,224499&chbh=18,10&chm=N,000000,0,,10|N,000000,1,,10|N,000000,2,,10|N,000000,3,,10|N,000000,4,,10|N,000000,5,,10&chds=0,2&chd=t:1.76|1.83|1.56|1.68|1.63|1.68&chxl=0:|filesystem|1:|0(MB/s)|0.5(MB/s)|1.0(MB/s)|1.5(MB/s)|2.0(MB/s)&chdl=ext4(writeback)|ext4(ordered)|ext3(writeback)|ext3(ordered)|xfs|ext2)
&chxt=x,y&chs=400x200&chg=0,10.50,1,5&chco=0092B9,86AD00,F2B705,BC3603,80C65A,224499&chbh=18,10&chm=N,000000,0,,10|N,000000,1,,10|N,000000,2,,10|N,000000,3,,10|N,000000,4,,10|N,000000,5,,10&chds=0,2&chd=t:1.74|1.74|1.79|1.46|1.77|1.12&chxl=0:|filesystem|1:|0(MB/s)|0.5(MB/s)|1.0(MB/s)|1.5(MB/s)|2.0(MB/s)&chdl=ext4(writeback)|ext4(ordered)|ext3(writeback)|ext3(ordered)|xfs|ext2)
&chxt=x,y&chs=400x200&chg=0,10.50,1,5&chco=0092B9,86AD00,F2B705,BC3603,80C65A,224499&chbh=18,10&chm=N,000000,0,,10|N,000000,1,,10|N,000000,2,,10|N,000000,3,,10|N,000000,4,,10|N,000000,5,,10&chds=0,100&chd=t:80.75|80.65|23.80|63.20|80.95|77.45&chxl=0:|filesystem|1:|0(MB/s)|20(MB/s)|40(MB/s)|60(MB/s)|80(MB/s)|100(MB/s)&chdl=ext4(writeback)|ext4(ordered)|ext3(writeback)|ext3(ordered)|xfs|ext2)
&chxt=x,y&chs=400x200&chg=0,10.50,1,5&chco=0092B9,86AD00,F2B705,BC3603,80C65A,224499&chbh=18,10&chm=N,000000,0,,10|N,000000,1,,10|N,000000,2,,10|N,000000,3,,10|N,000000,4,,10|N,000000,5,,10&chds=0,100&chd=t:77.05|77.95|15.20|69.45|79.20|27.65&chxl=0:|filesystem|1:|0(MB/s)|20(MB/s)|40(MB/s)|60(MB/s)|80(MB/s)|100(MB/s)&chdl=ext4(writeback)|ext4(ordered)|ext3(writeback)|ext3(ordered)|xfs|ext2)
&chxt=x,y&chs=400x200&chg=0,10.50,1,5&chco=0092B9,86AD00,F2B705,BC3603,80C65A,224499&chbh=18,10&chm=N,000000,0,,10|N,000000,1,,10|N,000000,2,,10|N,000000,3,,10|N,000000,4,,10|N,000000,5,,10&chds=0,140&chd=t:118.3|113.2|83.7|91.0|112.7|97.9&chxl=0:|filesystem|1:|0(MB/s)|20(MB/s)|40(MB/s)|60(MB/s)|80(MB/s)|100(MB/s)|120(MB/s)|140(MB/s)&chdl=ext4(writeback)|ext4(ordered)|ext3(writeback)|ext3(ordered)|xfs|ext2)
&chxt=x,y&chs=400x200&chg=0,10.50,1,5&chco=0092B9,86AD00,F2B705,BC3603,80C65A,224499&chbh=18,10&chm=N,000000,0,,10|N,000000,1,,10|N,000000,2,,10|N,000000,3,,10|N,000000,4,,10|N,000000,5,,10&chds=0,140&chd=t:118.9|114.8|92.7|89.4|117.5|98.3&chxl=0:|filesystem|1:|0(MB/s)|20(MB/s)|40(MB/s)|60(MB/s)|80(MB/s)|100(MB/s)|120(MB/s)|140(MB/s)&chdl=ext4(writeback)|ext4(ordered)|ext3(writeback)|ext3(ordered)|xfs|ext2)
メジャーなものとしてext2、ext3がありますが、現在ext4が主流になろうとしています。また、oracleが開発したBtrfs(B-tree file system)などのような、SSDへの最適化やCOW(Copy on Write)など次世代のファイルシステムが沢山あります。
そこで、あまり最新のものは今後やるとして、昔からあるファイルシステムと今のファイルシステムでどの程度パフォーマンスに差があるのか検証してみます。
* 本当はBtrfsも検証したかったのですが、SSDが不調なのとDIRECT I/Oが未サポートだったので断念しました
Linux 2.6.35 released, with Btrfs Direct I/O support and -ENOSPC handling of volume management operations, completing the -ENOSPC support.
ext2からext3がLinuxの主流になったとき、ext3のジャーナリング機能を嫌い、Oracle構築でxfsを使う方も多かったのではないでしょうか?何せ、xfsはメタデータのみジャーナリングを行い、実データに関しては基本知らんぷりという仕様だからです。そんな中途半端?なジャーナリングを備えたファイルシステムがなぜ、好まれるのか?
答えは簡単です。Oracleにとって実データのジャーナルは必要ないからです。OracleはデータベースのファイルをO_SYNCオプションを付けて、オープンします。それは、OSのファイルキャッシュが危ないことを知っているからです。Oracleが「書いた!」と思っても、実はファイルキャッシュにしか書かれておらず、実際のファイルには「書かれていない!」こともあり得るわけです。これを確実に「書いた!」もしくは「失敗した!」とするため(白黒はっきりさせるため)にO_SYNCオプションを付けてオープンしているわけです。
とりあえず、上記のように、ファイルシステムは沢山あって、ジャーナリングなど高機能を提供するものも多い。ただ、そのような高機能が不必要な場合もあるわけで、システムによって、特性を見極めてファイルシステムを選択する必要もあるかも知れない。というわけで、今回はファイルシステムの性能を測定してみました。
1. ext4(writeback)
2. ext4(ordered)
3. ext3(writeback)
4. ext3(ordered)
5. xfs
6. ext2
6パターンのパフォーマンスを比較してみます。前回と同じ測定方法です。
結果は、xfsが大健闘、甲乙つけがたい感じで、ext4のパフォーマンスが素晴らしい。逆にext3は、かなり苦戦を強いられている。xfsやext4はエクステントでブロックを確保するが、これが、読み込み時に有利に働くと思われます。
ただ、これを書いていて思ったのですが、今時みんなASMですかね。。。
質問1．writebackとorderedの違いは？意味は？
返信削除質問2．ASMだとOS File Cacheが使えなくなるでしょ？
例えば、sequential read/scattered readはOS file cacheが効果的に働くよね？Windows環境で僕のやったテストでは
http://ichiroobata.blogspot.com/2010/08/os-file-cache6.html”OS File Cacheで6倍のスピード ”となりました。
Parallel Queryを多用するDWHではos file cacheなんて関係ないdirect path readを使うけど、数本のHDDで行うTPC-CベンチマークならRAW deviceを使うASMが適切ではないような気がします。
回答1. writebackはファイルシステムのメタデータのみジャーナルを書きますが、orderedもジャーナルはメタデータだけですが、ジャーナルを書くタイミングが実データを書き込んだ後となるため、実データとジャーナルの整合性が取れる。なので実際、パフォーマンス面から考えると大きな差になりにくいと思います。ただ、複数のプロセスで同一データを更新する場合は、orderedの場合、それなりにcontentionが発生するのではないかと推察します。
返信削除回答2. その通り。DWHに対して、ASMは良いソリューションだと思いますが、TPC-Cのようなショートトランザクションでは、file cacheの威力はそれなりにあるものと推察します。これも、ちょっとテストするつもりです。
random read と random write で ext3(ordered) のほうが ext3(writeback) より大幅に速いのなぜでしょうか？
返信削除パフオーマンス面では ordered より writeback のほうが優れていると思っていました。
確かに、ちょっとおかしいですね。私の認識でもorderedよりwritebackの方が高速になるはずです。ただ、これは、全体的に言えることですが、今回は、ファイルキャッシュで左右されないようにvdbenchのオプションでo_directでread/writeを行っています。この場合は、(ここまで言って何なのですけが)ファイルシステムの影響は大きく受けないと思っています。なにせ、ファイルキャッシュをバイパスしているので。なので、このファイルシステム別のテストでパフォーマンス差が出るなら単純にジャーナリングの性能差だと思っていました。
返信削除で、話しを戻して、ext3のordered/writebackで想定のパターンと違っているのは(今のところ)よく分かっていません。物理デバイスも常に同じパフォーマンスが出せるわけではありませんし、微妙な条件によってバラツキがあるのかも知れません。このテストに関しては、もう少し継続して行う必要があるかも知れません。
早速、ご回答ありがとうございます。
返信削除興味深い結果ですね。