LinuxファイルI/Oチューニング 

Linuxは私の使っている範囲ではファイルI/Oがパフォーマンスボトルネックになっていることが多い。で、チューニングの情報を集めてみるのだが、なかなか役立つ情報を入手できない。
決まって全般的なチューニングの進め方について述べ、次にボトルネックの調べ方について述べる。
最後にチューニングパラメータ設定手順のヒントだけを非常に簡単に挙げておわってしまう。いや、どこがボトルネックなのか最初に一発で分かればいいよ? でも全般的なチューニングの進め方でそうしたドキュメントが述べている通り、色々な可能性を繰り返しチューニングしながらつぶしていかなきゃいけないんだよね。
そのためには具体的なチューニングパラメータの設定手順がなきゃできないんだよね。それを教えろよ!それを!

ということで、今回はLinuxファイルI/Oチューニングについて調べた。大きなファイルの書き込み(ex. cpコマンド)を行うと、システムが数秒間程度反応しなくなる症状が出ているのでこれを改善したい。またファイルの書き込み速度が非常に遅い症状も同時に出ている。

症状の様子を見ている限り、大きなファイルの書き込みが始まって終わるまでの間は別のファイルI/Oが待たされてしまい、lsコマンドの様な軽い処理も反応しなくなる模様。さて、ボトルネックはどこでしょう? って、ファイルI/O以外にありえるのか?

とにかく推測が正しいのであれば、解決方法は単一の大きなファイルI/Oにシステムを占有させないことに決まっている。となればI/Oスケジューラ(Linuxの用語では"I/O elevator")をいじるのが正しそう。色々と検索かけて、PDFファイルを読んでみたところやりかたは次のようなものらしい。

(1)Linux Kernel 2.4.x
現在のパラメータを調べる

# elvtune /dev/sdb

/dev/sdb elevator ID 2
read_latency: 2048
write_latency: 8192
max_bomb_segments: 6


お望みのパラメータ値を書き込む

# elvtune -r 1024 -w 2048 /dev/sdb

/dev/sdb elevator ID 2
read_latency: 1024
write_latency: 2048
max_bomb_segments: 6


-r 読み込みの最大時間
-w 書き込みの最大時間
-b 書き込みを一括して最大いくつまで同時に行うか

-rや-wの値の単位がなんなのかは明示された資料をみつけられていません。多分[msec]で、2048なら2秒ちょっとになるのでしょう。確かに大きなファイルを書き込みにいって待たされるけど8秒とかで処理されるような気がするなぁ。あくまで「気がする」だけだけど。
それからelvtuneは運用中に行っても安全、とわざわざ書かれていたので安心して実行して良い、はず。

(2)Linux Kernel 2.6.x
I/Oスケジューラの種類を選ぶ。Linuxの用語では"I/O elevator"を選ぶ訳ですな。

/boot/grub/grub.conf

title Fedora Core (2.6.16-1.2111_FC5 Deadline I/O elevator)
root (hd0,0)
kernel /vmlinuz-2.6.16-1.2111_FC5 ro root=LABEL=/ rhgb elevator=ELV quiet
initrd /initrd-2.6.16-1.2111_FC5.img


上記のようにkernel行にオプションelevatorを追加してやればよい。ELVには次のいずれかが入る。
Completely Fair Queuing(default) ―> cfq
Deadline ―> deadline
NOOP ―> noop
Anticipatory ―> as

(http://www.redhat.com/magazine/008jun05/features/schedulers/ より)

FedoraCore5の場合、/boot/grub/grub.confを書き換えてリブートすればよい。grub.confの変更はそれだけで有効になります。
それぞれのI/O elevatorの動作方法は上記URLに書かれているので心配な人は確認してほしいが、簡単にまとめると、

Completely Fair Queuing(CFQ)
 デフォルト。プロセスごとにI/Oキューを用意し、I/O帯域を公平に振り分けようとする。中規模から大規模なマルチプロセッサシステムや、複数のLUNやコントローラに対してバランス良く振り分けることが必要なシステム向け。

Deadline
 遅延を小さくすることを目的としたもの。realtimeシステムに近い動作を行い、ラウンドロビンで複数のI/O要求を公平にさばこうとする。5本のI/Oキューを持ちアグレシッブに順序入れ替えを行ってパフォーマンスを稼ぐ。

NOOP
 非常にシンプルなFIFO。大きなI/Oとかあったらシステムをブロックしそうだね。

Anticipatory
 アグレッシブな順序入れ替えを行って遅延を小さくしようとする。小さく遅いディスクを持つシステム向け。

となる。RedHat4では4つのI/O elevatorは組み込みだそうで、特に用意しなくてもデフォルトで使用できるとのこと。

まぁ、普通はデフォルトのCFQ、問題が起きたら他を試してみる、と言うことになろうか。I/O elevatorを選んでも解決しない場合、なにがしかのパラメータを変更することになる。まだ調べてないが、/sys/block/hda/queue/iosched/* とかをいじればよいらしい。Kernel 2.6.xになって/sys/が使われるようになったばかりであるため、しばしば変更が繰り返されている模様。なので sysctl でいじるのがよいのか、どうやればいいのかもよくわからん。

取り合えず2.6.xカーネルマシンでI/O elevatorをデフォルトのCFQからDeadlineに変更してみて、挙動がどのように変更されるかを見てみているところ。

コメント

I/O スケジューラの記事、参考になりました。ありがとうございます。
こうしたカーネルパラメータによるスケジューラの変更って、体感できるほど速度に変化があるもんなんですかね?個人的にはベンチマークソフトなどで数値化しなければ分からない程度の変化かなぁ?と思ったりしてるんですが…。

I/Oスケジューラ

I/Oスケジューラの変更によって体感速度の変化があったかどうかというと、私の環境(Linux Kernel 2.6)では多少感じられた程度ですね。

Linuxをワークステーションとして利用しているのですが、ウィンドウの切り替えや終了に待たされる時間が短くなったように思えます。多少とはいえ、体感できた(様な気がする)のであれば、それなりに性能向上が見られたのではないでしょうか。

この手のものをどのようにすれば、測定できるのかよくわかりませんが。一度試してみてはいかがでしょう。気に入らなければ戻せばいいだけですし。

色々やって感じたのは、

(1)Solarisのスケジューラは凄い!
澄ました顔して高い負荷でもきちんと動作しているのを当たり前だと思っていたけど、実は大変なことなんだ。
(2)Windowsのスケジューラもなかなか
いつも「腐っている」と感じているWindowsカーネルですが、I/Oスケジューラ部分はそれなりに振り分けてくれているんじゃないかしら。メモり管理は駄目駄目だと思うけど。

ということ。Linuxがひゃっくりしないようになるのはいつの事かしらん。

「ファイルの書き込み速度が非常に遅い症状」は、別マシンで発生している症状で、このマシンではまだチューニングを試していません。
キャッシュを殺したRAIDカードとの組み合わせでI/Oが非常に小さなサイズに分割されて実施されている、ということまでは判明しました。

返信おくれましたが、ご回答ありがとうございました。
たしかに僅かでも体感できたとすれば、それはベンチマークなどの数値的には相当向上しているのは間違いないですね。
チューニングやボトルネックの改善ってすごい技術的に面白いんですが、あまり成果がでないこともあり、そのときはコスト掛けた割にアウトプットが出ないので、ちとヘコみますが(笑)。

そそそ、チューニングって面白いので色々と時間をかけてやっちゃうんだけど、測っても違いが出なかったりしますよね。

カーネルの構築時の設定によりますが(RadHatがどうなってるのかは知らない)、最近の 2.6 なら echo deadline > /sys/block/*/queue/scheduler とかすると起動中に変更できますよ。

でも、バッファキャッシュ増やすとか、bdflushのタイミングを変えるとかした方が、感じる変化は大きいかも……

情報ありがとうございます。
手元のFedoraCore5で少し見てみました。
感想を2006/10/16のエントリで書いておきましたので参照下さい。

これって、2.6.30のext3のwriteback+cfq でも再現する?
ordered mode問題に見えるんだけど

Re: タイトルなし

kosakiさん、試していないので分かりません。
が、orderd mode問題って、
http://www.atmarkit.co.jp/flinux/rensai/watch2009/watch05a.html
とかで説明されているものだと理解しているのだけど、試した時のファイルシステムがext3だったかどうか...? 多分素のext3だっと思うので、原因がそこに絡んでいる可能性はあるのかも。
いずれにしてもある程度時間を掛けてみないと何とも分かりません。時間掛けても分からないかもしれないけど(笑)

承認待ちコメント

このコメントは管理者の承認待ちです

コメントの投稿















管理者にだけ表示を許可する

トラックバック

この記事のトラックバックURL
http://haginov.blog35.fc2.com/tb.php/45-9273b747

nice値を変える

nice, reniceというコマンドはけっこう知られていないかもしれない。ジョブの相対的な優先度を変更するコマンド。Influence scheduling priority with nice and renice(linux.com)を読んで、詳細な挙動を知...

  • [2006/11/30 22:13]
  • URL |
  • うるめねっと技研 - Linux派 - |
  • TOP ▲