ca-ttyの日記: samba の速度が遅い問題2 2
- まず iptables を停止させた状態で計測し
- それでだめなら、速度がある程度出ている旧サーバの smb.conf をそのまま新サーバに適用して計測
と考えたのだが、肝心のサーバは稼動しっぱなしであり何の仕事もしていないタイミングでなければ検証することができない。
そこで前言翻してクライアントの win7 側を弄ってみようとまず PING.EXE を触りはじめたのだが、
ping -f -l 8986 -n 1 192.168.0.1
などと何気なく実行してみたところ、なんか通らな…いつのまにか通らなくなってる? しらなかった そんなの… 1月4日に苦し紛れにジャンボフレームが通るように設定した際、爆速になっていたことを確認していたし、現にそのときその速度を利用して 2GB 程度のファイルを計13個転送したのだ。
Windows7 機の NIC のドライバの構成の「ジャンボ パケット」と書かれた欄は 9014 になっていて、 Debian 側の ifconfig の MTU も 9014 のまま。 PING.EXE さんは「パケットの断片化が必要ですが」というが、C/S 双方対応しているとなると、スイッチングハブが機能していないのだろうか。
といわけで Debian 側に sudo ifconfig eth0 mtu 1500、 Windows 側のドライバの「ジャンボ パケット」欄を「オフ」に設定したところ、80MB/s になった。
しかし全く納得がいかない。 ジャンボフレームが通るようにしたときは確かに速くなっていたことを確認したわけだし、 そもそも元々 MTU 1500 で運用していて速度低下の問題が起きたわけで、戻したら 80MB/s ではなく 1月4日時点の記録 4.5MB/s にならねば辻褄が合わないのではないか。 不可解きわまる。ワカラヌ。
で、ここまで書いたところで力尽きて寝てしまったのだが、目が覚めたので書き込もうと Win7 機を起動し、念のため速度を計ってみたところ、まさかの 250KB/s...
ホムラクルシイ。
アホか… (スコア:0)
それは典型的なパケットロスだろ。
まずそもそも問題の切り分けができてない。ぶっちゃけ、話にならないレベル。勉強しろハゲ。
だいたいからして、一言でジャンボフレームと言ったところで色々ある。
どうやら一般的な9kbyteを選択したようだが、
これ↑から
何も考えずに、すぐこの↑設定を行なったのだろうが、これが根本的な間違い。正に素人。
どうしてそのようになるかは自分で調べて貰うとして、結論だけ言うと9KB MTU=9014=9000という事実。
Windowsのドライバによって値が変わってるだけで、基本的に9kbyte MTUといったら9000。
ゆえにLinux側のMTUは9000に設定する。またpingのサイズも8972にする。これ常識。
Windows側は9014と称して9000を待ち受けてるんだから、Linux側が9014で返したってそりゃ通らない。
ついでにいっとくと、Path MTU Discoveryを落とすような設定がしてあったりするともう駄目。
大半のWindowsや市販のルータにはそうなってるものが多い。
基本、おのおのの内部ネットはPMTUに受け答えするが、外側からのPMTUは落とす。
だから当然Linux側からのPTMUは通らない。ゆえにパケットは断片化することなく単に消える。
嫌ならnet.*.ip_no_pmtu_discやその周辺を設定するなり、Windows側の所定の場所を訂正するなりしなきゃならん。
だが一番の問題点は、Sambaの速度が上がらないという問題に対してきちんと向きあっていないところ。
どうせまたsmb.confが自分流のアホみたいな設定で溢れているのだろう…。
ググって見つけたsocket optionsやら、よくわかりもしない癖につけ加えたaioオプションの類とか、無駄に列挙されたvfs objectsとか、etc... etc...
普通の人は、そういう時にはまずそこから直すもんだ。
max protocolをcifsにして、securityをshareあたりに設定し、他はフルデフォルト。とりあえずそれで運用する。
それで速度がでないならvsftpdでも上げて、そちらでも速度が出ないのか試す。
そうやって問題を切り分けて原因を調べてく。
ところがおまえさんみたいなアホは、どういうわけだか切り分けもせずにいきなりMTUを9kに変えたりする。
問題が解決していないのに、新たな問題が発生するようなことをするから当然ドツボにハマる。
何故こんな簡単な理屈がわからないのか…。
Re:アホか… (スコア:2)