2008年7月 7日

[samba-jp:20259] Re:NFSマウントしたところをSambaで共有して使うと非常に遅くなりました。

近藤です。

お世話になります。


> 奥山です。
>
>>>>>> "k" == kondo <nobuaki3.kondo@xxxxx> writes:

> k> SANSERVER側の/etc/exportsのオプションは、rw,no_root_squash,syncです。
> k> SERVER001側でのNFSマウントは、以下のようにしました。
> k> mount -t nfs -o nosuid,rsize=8192,wsize=8192 SANSERVERのIP:マウント元
> マウント先
> k> ※rsize=16384,wsize=16384でも症状は同じ。
>
> えー、最低でも -o に tcp は入れましょう。
>
> あと、rsize, wsizeが8192でOKなのは大昔の話。
> tcpにしたら、両方とも 65536 とかにしてしまいましょう。
> さらに倍でもOK。もっとも意味は無いと思いますが。

やってみました。
しかし、結果は同じくSamba上からはパフォーマンスは出ません。
1パケットのサイズは大きくなるのでしょうが、NFSクライアント側の
messagesを見ると not respondingとなっているのでlockd関係で何らかの
応答待ちをしているようです。つまりNFSサーバ側でなんらかの応答を
していない?

前のメールでも書きましたが、NFSクライアントにsshでログインして
NFSクライアントのローカルディスクからNFSマウントしたところへ
cpすると9.3Mbps程度のスピードは出ます。
Sambaを介してないと十分実用的でした。

rsizeとwsizeについては、HPのサポートにちょっと問い合わせしたときに
教えてもらった値で、1024〜16384で1024の倍数でないといけないと言わ
れたのです。全サーバがHPサーバでなかったため、
それ以上突っ込んで問い合わせすることができませんでした。

> CIFS/NFS chain をやるとIOが遅くなる理由の1つに、CIFSが64kで書き込んで
> いるデータを、8192byte でNFSに書き込んでいるから、と言うのがあります。
> 1つのCIFSリクエストを8個のNFS requestに分割したら…そりゃ遅いよね?

前述したようにnot respondingになっている点と、
tcpdumpして眺めていると連続的にパケットが来ているわけでもなく、
時々パケットが来ていて、書き込みが完了する寸前に一気にパケットが
ずらずら来ているような感じですので、8個に分割されたからという
問題でもないようです。

> あと、SAN側のRAIDは何でしょうか?

RAID5です。

> でもCIFSだと 64kbyteです。これぐらいなら、1ストライプ以上になってい
> ませんか??であれば、NFSもあわせなくちゃ。
> # NetAppが早い理由の1つはこの辺がちゃんとしているから。
> ## あ、一応EMCの製品もしていなくもなくもなくもなくもなくもなく……
> ### 高いDMX4をbackendに使ってください。DMX4-SSDなんかお勧め :p
> ### そうすると、バッテリーバックアップキャッシュが効いて早くなります。

SANはDELL製のEMCです。
DMX4ってファイバーチャネルスイッチのことでしょうか?
SANのシステムは、NFSサーバやバックアップサーバも含めて全体で
1つのシステムとなっていますので、FCスイッチもDELL製です。
一応4Gbps×2だったと思いますが...


投稿者 xml-rpc : 2008年7月 7日 11:11
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/75048
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。