11日、青山ダイヤモンドホールにおいて、OSDNが主催する「Linux Kernel Conference 2005」が開催された。Linux Kernel技術者の情報交換の場として定着しつつある同カンファレンスだが、5年目となる今年もKernel 2.6の話題を中心に興味深い講演が用意され、多数の来場者で会場は満員となっていた。本稿では当日の講演の中から、NTTコムウェアの野呂昌哉氏による「大規模DBサーバへのLinux適用 ～Kernel 2.6の実力を探る～」と題した講演の模様をレポートしたい。

現在Linuxのエンタープライズ市場への進出が着々と進んでいるようだが、その適用分野はWebサーバやアプリケーションサーバが中心だ。これらのサーバでは負荷分散による性能確保が行いやすいため、IAサーバによるコストダウンメリットが有利に働く。しかし、DBサーバのようにスケールアウトが難しい分野では、サーバ単体の性能、そしてOSがサーバの性能をきちんと引き出せるかが重要になってくる。そこで、野呂氏が行ったのが、Kernel 2.4/2.6を使った、それぞれのDB性能を測定するベンチマークテストだ。

テストは、とある商用DBMSと、NTTコムウェア独自のベンチマークツールを使用して行われたという。これは典型的な卸売業での使用を想定したもので、商品の発注や在庫の払い出し、配送などの処理をエミュレートする。ハードウェアも、Xeon MP 3.0GHzを4基搭載したIA-32サーバ、ファイバチャネルで接続された高速なストレージ、ギガビットイーサネットなど、計測対象外のボトルネックを極力排除するよう配慮して選択されている。また、スループットの計測前に、システムが安定するまでのランプアップ時間を15分確保するなど、性能比較のための条件をかなり厳密に定めた上でテストが行われたようだ。

さて、このテストの結果は、Kernel 2.6が2.4に対し、最大で1.6倍の性能を発揮したというものだった。野呂氏はこの結果に対し、テスト中に採集した様々な情報から要因を考察する。まず、CPU使用率の推移を見ると、Kernel 2.6ではデータベースへの同時接続数の増加が直接CPUの使用率に反映しているのに対し、Kernel 2.4ではiowait、idleが残り、CPUを使い切れていない様子が現れている。つまり、高速なストレージを使用しているにも関わらず、入出力が先にボトルネックになってしまうのである。性能差には、ストレージへの入出力方式が深く関わっていると考えられるだろう。

テストに使用された商用DBMSは、OSのファイルシステムを経由しない「Raw I/O」や、通常の「File I/O」などいくつかの入出力方式をサポートするが、このテストで使用したのは、ページキャッシュを使わずファイルシステムに直接アクセスする「Direct I/O」で、かつ「非同期 I/O」だったという。DBMSの入出力処理は、Kernelバージョンに関わらず、同一のライブラリ「libaio」の同一の関数を使用しており、差が出るのは「非同期 I/O」「Direct I/O」の実装が、Kernel 2.4とKernel 2.6で異なっているためだと思われる。結局、使用したディストリビューションでは、Kernel 2.4で「Direct I/O」がサポートされていなかったことが原因となっていたのだ。

「Direct I/O」が有効にならない場合、大量のメモリがページキャッシュに消費され、ファイルに関するデータ(メタデータ)を保持したページがメモリ上から追い出されてしまう。このため、メタデータの再読込が多く発生し、そのI/O待ちのためにCPUリソースのiowaitが増加してしまう。また、某商用DBMSは、非同期I/Oを設定しても同期I/Oを行う「pread」システムコールを大量に発行するという。preadがメタデータにアクセスする間、DBMSのデータファイルは特定のプロセスにロックされ、他のプロセスが同一ファイルを処理できなくなる。これが、CPUリソースのidle状態が増加する原因となるのだ。

野呂氏の結論は、Kernel 2.6ならば大規模DBサーバに充分適用可能であるというものだった。また、どうしてもKernel 2.4を使わざるを得ない場合、ディストリビューションが提供するKernelが、Direct I/Oをサポートしているか確認すべきだという。さらに、非同期I/Oといえどメタデータのアクセス中はファイルロックが発生するため、非同期I/Oの設定は行わない方が良いようだ。

講演では他にも、IA-32/64サーバの比較や、Kernel 2.6のI/Oスケジューラの持つ4種類のElevatorアルゴリズムを切り替えての比較など、非常に重要かつ具体的な検証が行われていた。今後Linuxが大規模DBサーバ分野へ進出していくとすれば、こういった検証作業の重要性はますます高まっていくことになるだろう。