ウチのお客さんは検索システムを提供しているカイシャなのだけれども、バッチが非常に遅い本番系システムがある。テスト系システムではバッチの実行時間は2時間程度なのだが、同じものを本番系に導入したら、8時間かかっている。なんじゃこりゃ～～！みたいな感じ。
時間が掛かっているのは、xargsコマンドを使って数十万個のファイルを1つのデータファイルにまとめている処理の部分であった。
どうもディスク（RAID）が怪しいので、vdbenchの使い方で紹介したようにvdbenchを使って様々なパターンのテストを実施した。量が多いし、本題から外れるので結果は割愛するが。
- シーケンシャルなリード
- シーケンシャルなライト
- ランダムなリード
- ランダムなライト
- シーク割合50%のリード
- シーク割合50%のライト
- シーケンシャルなリード50%・ライト50%
- ランダムなリード50%・ライト50%
- シーク割合50％のリード50%・ライト50%
- 前項はすべてページキャッシュを使用した通常の使用条件のものであるが、これらすべてに対して、Direct I/Oによるケース
いずれのケースでも、180秒間、最大I/Oレートで負荷をかけてデータ転送速度を測定する。
このテストで分ったことは、平均的なパフォーマンスは本番系サーバーのほうがテスト系サーバーよりも良いのだけれども、シーケンシャルなディスクライトに関しては、本番系のパフォーマンスがテスト系の約1/4になっている。
この結果を見て、妙に納得した。バッチで時間が掛かっている問題の部分は数十万個のファイル群をひとつにまとめている部分であり、ここでの処理は殆どシーケンシャルなディスクライトとなっているはずである。その処理で本番系が1/4のパフォーマンスであるならば、確かにバッチの実行時間が4倍に延びそうだ。
いやぁ～、原因が分ったね、シーケンシャルなディスクライトが遅いんだって。よかったよかった・・・・ぢゃなくて！！
8時間をどうにかしようよ。もともと2時間の予定だったのだから。
そこで本記事の表題を実施してみようということになる。ext3/4のチューニングだ。Redhat Enterprise Linuxでは6までは、デフォルトでext系のファイルシステムを採用している。RHEL7になると、XFSがデフォルトになるそうだ。そろそろext系ファイルシステムのチューニングについて記事を書いておかねばならないと思いました。
まず、この無茶遅い本番系サーバーの正体をお見せいたしましょう。DELLのサーバーである。（DELLがすべて遅いというわけではございません。念のため。）
DELLのサーバーのRAID管理（情報表示）コマンドはomreportコマンドだ。OpenManageのパッケージを入れると一緒にインストールしてくれる。これは、以下の場所にあるので、PATHを通しておこう。（最近は、/usr/binにも存在していたりする。）一般ユーザーで実行可能。
/opt/dell/srvadmin/bin
$ ll
合計 2380
-rwxr-xr-x 1 root root 750 4月 8 2010 finddev.sh
-rwxr-xr-x 1 root root 49828 3月 8 2011 iDRACfl32l
-rwxr-xr-x 1 root root 97104 3月 8 2011 iVMCLI
-rwxr-xr-x 1 root root 1741887 3月 7 2011 idracadm
-rwxr-xr-x 1 root root 9543 2月 15 2011 ivmdeploy.sh
lrwxrwxrwx 1 root root 11 12月 27 2011 omconfig -> stdcliproxy
-rwxr-xr-x 1 root root 314 3月 7 2011 omexec
lrwxrwxrwx 1 root root 11 12月 27 2011 omhelp -> stdcliproxy
lrwxrwxrwx 1 root root 11 12月 27 2011 omreport -> stdcliproxy
-rwxr-xr-x 1 root root 72 3月 7 2011 omupdate
-rwxr-xr-x 1 root root 6941 3月 7 2011 racadm4
-rwxr-xr-x 1 root root 138546 3月 7 2011 racvmcli4
-rwxr-xr-x 1 root root 84 3月 7 2011 stdcliproxy
-rwxr-xr-x 1 root root 9575 3月 16 2010 vm6deploy.sh
-rwxr-xr-x 1 root root 269588 3月 8 2011 vmcli
$
まず、DELLのモデルを調べる。
Chassis Model : PowerEdge R710
$
次に、RAIDコントローラー情報。
Name : PERC H700 Integrated
$
RAIDコントローラのIDは：
ID : 0
Slot ID : Embedded
$
IDは0だ。これでようやくRAIDの構成情報を引き出せる。
Layout : RAID-10
$
RAID10だ。RAID10はストライピング＋ミラーリングをしているのだけれども、一般的に書き込みが遅い。更に、このサーバーを購入した時期（2011年ころ）からは、ハードディスクの物理セクターサイズが4KBとなり始めた時期だ。OS側から見える論理セクターサイズは伝統的な512Bだけれども、ディスクコントローラはセクター1つに書き込みをするために、4KBをまるまる読み出して、更新したものを含んだ4KBのブロックをまとめて書き込まなければならない。つまり、もともと遅いRAID10に更に4KBセクター初期の実装とあって、シーケンシャルライトがべらぼうに遅くなってしまったけれども、平均すると性能はいいよみたいな製品なんだろうね。
ファイルシステムのチューニングとは関係ないけど、ディスクライトのパフォーマンスに深刻な影響を及ぼす特別な因子が存在するので言及しておきたい。それは、ディスクのライトポリシーだ。
Write Policy : Not Applicable
$
DELLの場合、普通はこうなっている。"Not Applicable"だ。このときは、RAIDコントローラにキャッシュメモリが載っていれば自動的に"Write Back"に設定されている。"Write Back"では、ディスクへ書き込むつもりでキャッシュメモリに書き込みを行うので、OS側から見たディスクライトが体感上早くなる。
RAIDコントローラのメモリをバックアップしているバッテリーが低電圧状態になるとバッテリーチャージが始まるが、そうするとここが"Write Through"になる。"Write Through"では、キャッシュメモリを利用しないので、OSの書き込み命令は直接ディスクヘッドのシークを引き起こし、べらぼうにディスクライトが遅くなる。ハードがへたってくると、このバッテリーチャージが頻繁（数日に1回など）に起こるようになり、迷惑極まりない。データが飛んでもパフォーマンスを出したい！というならば、"Force Write Back"というポリシーに変更してしまえば、バッテリー低電圧状態云々を問わず、常に"Write Back"となる。しかし、この件は顧客とよく相談して実施することだ。データが飛ぶからね。電源の瞬断などがあったりするとね。
...
Virtual Disks
ID : 0
Status : Ok
Name : Virtual Disk 0
State : Ready
Encrypted : Not Applicable
Layout : RAID-10
Size : 278.88 GB (299439751168 bytes)
Device Name : /dev/sda
Bus Protocol : SAS
Media : HDD
Read Policy : Not Applicable
Write Policy : Not Applicable
Cache Policy : Not Applicable
Stripe Element Size : Not Applicable
Disk Cache Policy : Disabled
#
controller=0の部分は、先に調べておいたコントローラIDを入れる。デバイスネーム（この事例では/dev/sda）は目的のパーティションを含んでいるかい？よく確認しておこう。"Virtual Disk 0"が分ったので、omconfigコマンドでライトポリシーを"Force Write Back"へ変更する。rootユーザーで実行しよう。
#
きちんと変更されたかを確認する。
Write Policy : Force Write Back
#
さて、それにしても、いやぁ！罪深いサーバーだよ、DELL PowerEdge R710！よしよし、これから「本題」のファイルシステムのチューニングをしてやるからな！
参考にした記事は、Mount options to improve ext4 file system performance。ext4となっているが、ext3でもほとんど同じ。ext4の詳細については、Ext4 Filesystemを参照のこと。ext3の詳細については、Ext3 Filesystemを参照のこと。
前出の参考記事によると、railsテストスイートが30%早くなったらしい。もっと早くなるといいな。
さて、ファイルシステムオプションを変更するには、/etc/fstabを編集して目的のパーティション一度アンマウントした後、再マウントしなければならない。目的のパーティションを使用しているプログラムがあるとアンマウントできないのでご注意を。ルートパーティションはアンマウントできないし、/homeなども作業用のシェルでログインしているならばアンマウントできない。その様な場合には、/etc/fstabの変更内容を反映させるためにOSの再起動が必要になるのでご注意を。
以下の例では、/dataパーティションについてファイルシステムオプションを変更するものとする。
# cp -p fstab fstab.yyyymmdd
# vi fstab
...
/dev/VolGroup_ID_12106/data /data ext3 noatime,data=writeback,barrier=0,nobh,errors=remount-ro 1 2
#
変更箇所は、"defaults"と書いてあるオプションの部分を"noatime,data=writeback,barrier=0,nobh,errors=remount-ro"に書き換える部分。オプションのそれぞれの意味は、noatime（ファイルのatimeを記録しない）、data=writeback（ファイルシステムデータをライトバックとし、データ順序を保証しない）、barrior=0（ライトバリアを不活性化する）、nobh（バッファヘッダを使用しない）、errors=remount-ro（エラー時にはリードオンリーで再マウントする）。
/etc/fstabを書き換えたら、ファイルシステムを一度アンマウントし、再マウントする。
# sync
# sync
# umount /data
# ls -l /data
# mount /data
最後のmountコマンドは/etc/fstabに記載されたパーティションのみを引数としているが、その場合は、/etc/fstabの内容を再読み込みして、そこに記述されたオプションでマウントする。
シスログを見てみよう。
# tail messages
...
Apr 15 10:25:53 jalintl3 kernel: kjournald starting. Commit interval 5 seconds
Apr 15 10:25:53 jalintl3 kernel: EXT3 FS on dm-6, internal journal
Apr 15 10:25:53 jalintl3 kernel: EXT3-fs: mounted filesystem with writeback data mode.
#
"EXT3-fs: mounted filesystem with writeback"と出ていれば設定がきちんと効いている。ここに、"EXT3-fs: mounted filesystem with ordered data"と出るならば、設定は反映されていない。もう一度やり直しだね。
さて、このファイルシステム設定変更の前後でvdbenchを使ってシーケンシャルライトのパフォーマンステストを実施した結果は：
| Page Cache | FS条件 | fstabオプション | 転送速度 | 平均応答時間 | 最長応答時間 | 応答σ |
| MB/sec | ms | ms | ||||
| 利用なし(O_DIRECT) | FSチューニング前 | default(ordered data mode) | 83.7 | 0.372 | 35.496 | 1.683 |
| FSチューニング後 | writeback data mode etc. | 83.36 | 0.374 | 349.757 | 1.822 | |
| 利用あり(通常条件) | FSチューニング前 | default(ordered data mode) | 135.04 | 0.231 | 3245.42 | 7.23 |
| FSチューニング後 | writeback data mode etc. | 1037.98 | 0.029 | 4.769 | 0.082 |
赤いセルに注目して欲しい。ページキャッシュを使用しないO_DIRECTのディスクI/Oでは、チューニングの効果が全く感じられないが、ページキャッシュを使用する通常の利用条件においては、劇的な転送速度の改善（ 1037.98 ÷ 135.04 ＝ 7.63倍）が見られた。約8倍とすれば、テスト機の1/4のパフォーマンスだった本番機が、一気にテスト機の2倍のパフォーマンスになりうるということだ。
すばらしいぢゃないか。でも、担当SEのS氏、このファイルシステム設定の恒久化に躊躇してしまっているんだよね。まぁ、顧客から突き上げられたときの奥の手として残しておくのもいいんだけど、本番化できないのはちょっと残念だね。
noatimeの件についてだけれども、ファイルのatimeを記録しないで大丈夫なの？ということで、ウチのお客さんのところで利用しているファイルシステムにデータを記録するPostgreSQLについて調べてみたけれども、PostgreSQL Performance Tuning - Tune the Operating System - File Atimeによると、どうもatimeの情報を使っていないようで、ファイルシステムにnoatimeオプションを付けてデータファイルのパーティションをマウントするように推奨している。S先生。安心してファイルシステムオプションを変更してもいいと思うよ。
コメント