Kernel 2.2.x におけるディスクの同期、非同期のパフォーマンス差

最近、本業のデータベースシステムのパフォーマンス劣化で悩む日々が続いております。いろいろ分析をしているのですが、何しろ Miracle Linux 1.0 を使っていて、Kernel が 2.2 系とちょっと古いのが痛い。情報が少ないんですよね・・・。

さて、パフォーマンスの問題は更新型データベースにありがちな、I/O 周りのパフォーマンス問題。

Linux の I/O 関係は Solaris に比べるといろいろと問題が発生しやすいのも事実で、例えば、とあるベンダーでは Ext3 を別名Exorcist3 （エクソシスト３）と皮肉ったりしています。実際、ウチの環境では Kernel 2.2 系のサーバで Ext3 を使ったパーティションは、良く問題を起こします。例えば、

ジャーナルファイル破損
mount を非同期モードの async にすると、メモリ上だけのデータが更新され物理ディスク上は更新されず不整合が発生

なんて問題です。

- スポンサーリンク -

Kernel 2.6 系で I/O 周りは随分と改善されたようで、Ext3 周りのコードもかなりの改変が入っているようで、信頼性とかパフォーマンスが向上しているようですが、今そんなことを言っても仕方がない。取りあえず、現状を調べることにしました。

今回のボトルネックは I/O ネックと事前に判明していたので、いろいろと調査してみたら mount の同期(sync)、非同期(async) で面白い違いがでました。下記結果は、Oracle が動いているサーバに対して擬似的に insert を数万件連続で発行して、その時の vmstat を解析した結果です。

Kernel 2.2 系や 2.4 系の sync モードってパフォーマンスが凄く悪いと言われているのですが、それを実証する結果となりました。同期モードでは I/O 待ちプロセスが頻発して、更なる I/O 待ちを生むという自体になってしまいました。async の場合は、あるタイミングで瞬間的に物理ディスクへの write を発行し、I/O プロセス待ちが極力発生しないように頑張っているのがわかります。

2ch で見かけたのですが、Hacker な方達が Kernel を解析して語っているように、Linux の sync では本当の同期を保証できないそうです。なので、結局 sync も async も安全性の保証という点で大差がないので async を使えと。

参考になるページ

/**ファイルシステム総合スレその3**/　→　ぶっちゃけunmountの時だけsyncすればいい気がする。
ジャーナリングファイルシステム　→　高健全性度は journaling > sync write > soft update > async write
Server File Cache → Storage　→　各種 Filesystem の仕組みの解説
Softupdate のひみつ　→　oftupdate が安全で高速な技術的理由の解説
Linux V2.2 カーネル内部解析報告第3 版

Server File Cache → Storage の解説によれば、

ext2 は複数のバグが絡み合って、結果として同期的書き込みが全く保証されない。 user data の disk への書き込みは、 write システムコールに対する O_SYNC フラグを付与しても、 fsync システムコールを呼び出しても、 sync システムコールを呼び出しても、保証されない。 umount によってのみ、dirty page は 100% 反映される。
と言うことは、 ext3 層が ext2 に Journal を書いてくれと頼んでも、 Journal 記録が disk に書き込まれる保証はないという事を意味する。さらには、ext2 は書き込み順序にエレベーターシークアルゴリズムなどを用いるので、 Journal ファイルへの Journal 記録の反映順序保証さえない事になる。

だそうです。

ちなみに、/fs/sync.c ってのが Filesystem の同期、非同期を実装する Kernel ソースになるわけですが、見ても難しくて洋裁を理解できませんでした・・・orz

最後に、パフォーマンスチューニングの基本のお話し。チューニングってのは、ボトルネックの特定とその対策をすることです。具体的には、

メモリネックなら、メモリの追加もしくは、アプリケーションのメモリ関連のチューニング
CPU ネックなら、CPU の増設やより高速な CPU への移行
I/O ネックなら、増設や RAID 化による I/O 分散、より高速な DISK への移行、アプリケーションのチューニング
ネットワークネックならより高速なネットワーク機器の導入

と言った感じです。実際には、ハードウェアのスペックを上限まで使い切っている場合も多いので、OS やアプリケーションレベルでのチューニングがかなり重要になってきます。Linux の場合、次の手順を踏むのが基本です。

CPU 使用率の測定

vmstat の cpu で us,sy が 100 に近く、id が 0 に近ければ cpu がネック
sar -u でも同じ内容が得られる

プロセスの状況の測定

vmstat の r が cpu 数以上なら実行可能プロセスキューが cpu 待ちをしている状態なので cpu がネック。
b が 0 以上なら I/O 待ちで割り込みが禁止されたプロセス数があることを意味するので I/O がネック。
w の値は Linux においては他の値からの計算値になるので swap を示しているわけではないので参考外。Solaris は swap を示すので 0 以上ならメモリ不足。

メモリ使用量の測定

vmstat の memory で swpd が 0 以上ならスワップを使用中でありメモリ不足。
free が少なくても swpd, si, so が 0 なら OS が buff,cache に割り当てているだけなので問題なし
sar -r でより詳細情報が解析可能

Disk I/O の測定

vmstat の bi,bo が多い場合、ブロック転送が頻発している。多くの場合、スワップによる I/O 多発を意味するのでメモリ不足。スワップが原因でない場合、その他の原因による I/O ネック。
sar -b でより詳細情報が解析可能
sar -B の pgpgin/s,pgpgout/s が多い場合、ページングが頻発している。ページングは OS のメモリ管理上発生するものなので、通常は問題ないが負荷が高い場合は、/proc/sys/vm/freepages をチューニング（kernel 2.2 の場合）。
メモリ不足が原因の場合もある。

スワップ状況の測定

vmstat の si,so が多い場合スワップが発生しているのでメモリ不足
sar -W の pswpin/s,pswpout/s も同じ意味。

平均待ち時間の測定

iostat -x の await が大きい場合、I/O 待ちが頻発している。I/O ネック

Diskキューの測定

iostat -x の avgqu-sz が大きい場合、I/O 待ちが頻発している。I/O ネック

です。vmstat や sar の使い方やインストール方法については、google とかで調べて下さい。各々取得したデータは Excel とかでグラフにすると視覚的に解りやすくなります。

Linux の場合は、OS 上のチューニングとしては最低限下記のことを考えて設計すると良さそうです。