ext4なファイルシステム環境を使う際の注意点

つい先日こんな日記を書いた。

サーバのHDD

原因はディスクI/Oだ！という結論は決して間違っていなかったんだけど、根本的なことを理解していなかったばっかりに、この日記を書いたあとも多いにはまりましたよ…という話。

そもそも今回の件って、さくらインターネットの専用サーバを新規に借りて、そこにRHEL6をのっけたところがスタートだったわけです。で、サーバが利用できるようになってから、サイトのセットアップを済ませ、いざ運用テストを行ってみた段階で、DBに対する書き込みのパフォーマンスが全然あがらない。なのでHDDの障害を疑って、そして再セットアップまで行ってもらったというのが前回の話。

ただ、再セットアップしてもらった環境で、改めてベンチマークとってスループットチェックを行っても、全然パフォーマンスが変わらないわけです。ベンチマークに利用したdbenchの傾向として、Flash項目だけずばぬけてレイテンシーが低いので、何かしらの理由でディスクへの書き込みに時間が掛かっているだろうことは想像がつくんだけど、その理由というやつが全然わからない…。この辺りは、Linuxのファイルシステムについての知識が全然なかったのが手こずった理由なわけで。勉強不足でしたね。

で、いろいろな環境でベンチマークとってみました。結果、RHEL6をそのまま使っても状況が改善されないけど、RHEL5環境であればパフォーマンス上の問題がおこらない、というところまでは把握できたので、とりあえず利用するOSをRHEL5にすることで逃げることにしました。

とはいえ…、今後はRHEL6を積極的に導入していきたいし、でもそのためにI/Oを犠牲にするのでは意味がないしで、なぜゆえRHEL6だとここまでFlashに時間がかかるのか、その理由が知りたい。けど、自分の知識では、何をどう調べればその解答にたどり着くかもわからない。そこで、ダメ元でさくらインターネットのサポートに投げてみました。「なぜRHEL6だとここまで遅くなるのか？」と。問題の丸投げだー。

すると、その原因を調査してくれましたよ。原因は、RHEL6で標準導入されているファイルシステムext4の問題らしい。RHEL5からRHEL6になって、ファイルシステムがext3からext4に変更になったことは私も把握してたし、くさいのもこの辺だろうとは思いつつ、じゃぁなんでext4だと遅くなるのかの理由がさっぱりだったんだけど、どうやらext4のオプションとして指定できるbarrierが有効になっていると安全性を得る代わりに多少のパフォーマンス低下を招くらしい。多少…？

JF - Ext4 ファイルシステム

そこで、barrierを無効にするとどのくらいパフォーマンスが変わるのか。さくらインターネット側でdbenchを実行してくれました。するとこんな結果に。

 Operation      Count    AvgLat    MaxLat
 ----------------------------------------
 NTCreateX    5401295     0.015    14.912
 Close        3967673     0.001     4.709
 Rename        228714     0.044     8.743
 Unlink       1090740     0.039   109.136
 Deltree          138     4.512    12.438
 Mkdir             69     0.003     0.030
 Qpathinfo    4895749     0.007     8.410
 Qfileinfo     858001     0.001     3.046
 Qfsinfo       897692     0.002     2.019
 Sfileinfo     439978     0.026     9.029
 Find         1892827     0.022     8.749
 WriteX       2693270     0.027    16.678
 ReadX        8466843     0.005     8.958
 LockX          17588     0.003     0.052
 UnlockX        17588     0.002     0.636
 Flush         378562     2.064  2659.157

Throughput 283.143 MB/sec  2 clients  2 procs  max_latency=2659.160 ms

同じ環境でbarrierが有効になってた時のベンチマーク結果が

Throughput 6.63792 MB/sec 2 clients 2 procs max_latency=329.013 ms

だったので、パフォーマンスの違いは明らか。まさかここまで変わるものだとは…。当然、ext4のデフォルト設定でbarrierオプションが有効になっているのは、それ相応の理由もあるだろうから、実運用するサーバでこのオプションを無効にしてしまっても平気なのかという問題はある。そこは、無効にすることでどういうデメリット、リスクが発生するのかということをしっかりと理解しないといけないんだけども、このパフォーマンスの差をみると、ディスクへの書き込みが頻発する環境でbarrierを有効にした運用って厳しいと思うんだよなぁ…。RHEL6を既に運用してる人達って、このへんどう割り切ってるんだろう？非常に気になるところではありますね。

あと、今回の件では、OSの再セットアップを都合3回もやってもらった上に、ベンチマークとるための協力だったり、RHEL6の問題調査だったり、さくらインターネットのサポセンには大変お世話になってしまいました。もろもろご協力いただき本当に助かりました！そして良い勉強にもなったな。もっと精進しないとな…。