- - PR -
XenでのNFSサーバの使用について
1
投稿者 | 投稿内容 | ||||
---|---|---|---|---|---|
|
投稿日時: 2008-01-23 19:07
皆様こんばんは。
いつも質問してばかりで恐縮です。 現在、Xenで仮想マシンを構築しており、domUはNFSサーバ上のOSイメージファイルから起動しています。 <dom0> hp ProLiant BL460c QuadCore×2、10GBmem(ブレード) CentOS5.1 | | ←NFSv3(ギガビットイーサ) | <NFSサーバ> hp ProLiant BL465c Opteron、4GBmem(ブレード) CentOS5.1 NFSサーバには、SB40cと言う2.5インチのDiskが6本入るエンクロージャと直結させています。実際に搭載しているDiskは10,000回転、SASディスクです。 ここで性能的な問題があって、domU上で外部FTPサーバへ接続し、大きめなファイル(100MB〜)をftp getすると、書込みにものすごく時間がかかり、domU自体へのコマンド実行なども重たくなります。もちろんFTPサーバへもギガビットで接続されています。 そこでNFSサーバ、dom0上で色々とstatをとってみたのですが、分かったことは 1.NFSサーバ自体のDiskIOなどの劣化は見られない(vmstat,mpstat,iostatもidleが99%程度でwaitはほぼ0%) 2.dom0上で、NFSサーバからマウントしているディレクトリに同様なftp getを実行しても性能劣化は見られない。 3.domU上でFTP転送中、dom0には性能劣化が見られない(vmstat,topなど実行してもidleが占めている) 4.domUからFTP転送中、NFSサーバ上でps axコマンドを実行すると、nfsdデーモンすべての「STAT」が「D」となっている。 「4」に示しているとおり、domU上でFTP転送中に、nfsdがひたすら待ち状態になったいるため、NFSサーバ上で書込み処理を実行できていないといったことが原因で性能が劣化していると思われます。 NFSサーバの設定 ・CentOS5.1 64bit 2.6.18-53.1.4-el5 ・nfsdの数:8(デフォルト) ・/etc/exports /vm 192.168.1.0/24 (rw,no_root_squash,sync) dom0 ・CentOS5.1 64bit 2.6.18-53.1.4-el5xen ・/etc/fstab 192.168.1.x /xen nfs rsize=32867,wsize=32768,intr,hard 0 0 domUは、NFSサーバ上のエキスポートディレクトリ/vmの中に保存してあるOSイメージファイルから起動しています。 NFSv3を使用しています。 ちなみに、dom0が使用しているCPUコアとは別のコアを固定で割当てています。 やってみたこと ・NFSのマウント時、バッファサイズをデフォルト、32KBと変えて同様のテストをしましたが変化がありませんでした。 ・NFSサーバのデーモン数をデフォルトの8から16、32と変えて同様のテストをしてみましたが、変化がありませんでした。 ・NFSとの接続に、デフォルトTCPのところをUDPに変更して、同様のテストをしてみましたが、変化はありませんでした。 なので、ボトルネックはNFSDのプロセスだろうと思っています。 このような経験をされた方はいらっしゃいますか? 他に見るべき、変えてみるべきパラメータはありますか? そもそも、Xen環境でのNFSサーバの使用は、性能的にこんなものでしょうか? 100MBのファイルダウンロードするのに1分程度掛かってしまいます。 乱文で申し訳御座いません。宜しくお願いします。 | ||||
|
投稿日時: 2008-01-24 13:18
FTP転送中のdomUの状態、NFSサーバの状態をチェックしてみました。
気が付いた点 1.FTP転送中、domUのpdflushスレッドのSTATが「D」である。 2.FTP転送中、NFSサーバ上でiostatを実行すると、転送完了にもかかわらずwriteblock/sの値がFTP転送中のそれと同じくらいの値でかなりのライトが走っている。 これらの結果から推測できるのは、ファイルを書き込む際に発生するダーティページのディスクフラッシュ処理でnfsdと通信するためnfsdプロセスが「使用中」となって、domUのpdflushがまっているのではないかということです。 ページフラッシュでのnfsdとの通信を軽減できれば若干の性能向上が見込まれると思います。しかし、ページフラッシュする動作自体はLinuxにおける正常動作なので、根本原因を改善できるわけではないと思います。 ある意味、Xenの仮想マシンをNFSサーバのディレクトリから起動するような構成では、このボトルネックが発生するのは当然なのでしょう。 ページフラッシュするタイミングvm.dirty_ratio、vm.dirty_background_ratioなど変えてみてもあまりかわら無そうな気がします。 ここらへん、良い知恵は無いでしょうか。 | ||||
|
投稿日時: 2008-01-24 18:35
dom0のマウント時のオプションで、rsizeとwsizeの値を、それぞれデフォルトの32768→4096に変更して試してみました。
デフォルトの値の場合よりも転送性能的には8倍向上しました。 気になっていたコマンドのレスポンスの悪さもデフォルト値よりはよくなった気がするのですが、それでもまだまだ悪いです。 一般的にはクライアント側のバッファサイズは大きい方が性能が向上するといわれますが、 試したところ、Xen+NFSサーバではwsizeを4096よりも大きくすると性能が悪くなります。 これは仮想マシンのダーティなページキャッシュをフラッシュするときの書き込みブロックサイズが4096byte単位だからなのかなぁと思っています。 試した結果を以下に示します。 rsize wsize 性能 32768 32768 1.7MB/s程度 4096 4096 8.5MB/s程度 32768 4096 6.5MB/s程度 4096 32768 1.1MB/s程度 rsizeを8192や、1024、2048と変えてやってみましたが、rsize=4096,wsize=4096が一番よい性能を発揮します。 Xenの仮想マシンイメージをNFSサーバからブートするような構成では、必ずこの問題にぶち当たると思います。 結果的に性能向上できましたが、実はいまいち納得できていません。 | ||||
|
投稿日時: 2008-01-25 02:19
こんばんわ。
| Xenの仮想マシンイメージをNFSサーバからブートするような構成では、必ずこの問題にぶち当たると思います。 | 結果的に性能向上できましたが、実はいまいち納得できていません。 なぜ、納得出来ないのか理由が述べられてませんが仮想マシンをNFS等に置く以上、 性能低下は回避できないのではないでしょうか? NFSを利用せずにdom0のディスク上で稼働させた場合のレスポンス評価をして見ては 如何でしょうか? そもそも、NFSのパフォーマンス評価って高いのですか? | ||||
|
投稿日時: 2008-01-25 09:21
ドメインUにはOSイメージファイル1つだけを割り当てているということでしょうか? 実現したいことからはずれるかもしれませんが、ドメインUから直接NFSをマウントしてみてはいかがでしょうか? ドメインUのファイルシステム分ぐらいは早くなるかもしれません。 |
1