//-- S A M B A --//

[276:名無しさん＠お腹いっぱい。 (02/02/15 19:32)]
WindowsってWindows同士でいいパフォーマンス出るようチューニング
してるみたいだし、OSのバージョンによって色々挙動違うからねぇ。

samba側としては、smb.confのsocket optionsいじる事になるんだと
思うけど、具体的に何をどう設定するかまでは俺覚えてないや。

その辺のチューニング方法についてのドキュメント(確か奥山氏辺り
が書いた奴)がsamba-jp辺りにある(というかsamba-jp MLに流れてた
記憶があるので、多分samba-jpのWeb page上にもあるだろう)と思う
ので探してみてくんろ。

[277:名無しさん＠お腹いっぱい。 (02/02/16 00:34)]
>>275
だいたい、コレで最適なパフォーマンスがでます

socket options = IPTOS_LOWDELAY TCP_NODELAY SO_SNDBUF=16384 SO_RCVBUF=16384
readsize = 16384
read prediction = true
getwd cache = yes
level2 oplocks = true
strict sync = no
wide links = no
write cache size = 262144 #これはファイル当たり256kバイトのキャッシュサイズである
今までとパフォーマンス全然違うぞ！やってみ。

[278:名無しさん＠お腹いっぱい。 (02/02/16 01:30)]
loglevel(?)=0
も結構速くなる。

でも、なんでSMBってこんなにオーバーヘッド大きいんだ？
Windowsからのディレクトリアクセスもファイルが増えると極端に遅くなるし。
lsのアクセスとかだと高速なのに、ネットワークドライブにdirとかするとかなり遅い。
ファイルの多いディレクトリをWindowsで共有させると、カーネル使用率が滅茶苦茶に上がる。

なんか、Windows、DOSのディレクトリアクセスか、SMBの仕様に問題があると思う。

[279:名無しさん＠お腹いっぱい。 (02/02/16 01:35)]
>>277
そこに至った経緯というか、各数値の根拠が知りたいざんす。

[280:名無しさん＠お腹いっぱい。 (02/02/16 01:53)]
>>277
かぎりある資源なのだから降伏点がどこかにあるはず
っていう意味で、そこに至った経緯は知りたいところだあねえ

[281:名無しさん＠お腹いっぱい。 (02/02/16 02:01)]
>>278
ローカルのFSへの排他＋Windowsの資源としての排他＋伝送手順の仕様で
レスポンスが悪くなるんだろうねえ
とはおもうけども実際解析してないからよぐわがんね

[282:277 (02/02/16 02:30)]
これに至った経緯:
試行錯誤して、速くなったから。ただそれだけ。

[283:名無しさん＠お腹いっぱい。 (02/02/16 13:28)]
>>281
Windows（ローカル・fat）でも再現するんですよねー。
うちだと2000を超えたあたりから、マウスがぎこちなくなってくる。
アクセスした一瞬だけ総ての動作がフリーズする感じ。

[284:名無しさん＠お腹いっぱい。 (02/02/16 14:11)]
>>282
どうも。
つまり、これってネットワーク環境とかで大きく左右されるってこと？
NICの種類やハブの性能がわからないので
これをそのまま実施するのもちょと気が引けるというか
すまん

ある程度これらの値を環境から計算で求められないかな？

[285:名無しさん＠お腹いっぱい。 (02/02/16 14:38)]
>>283
おなじおなじ。
ローカルのFS＝Windowsの内部制御ロジック
Windowsの資源としての排他＝むかしっぽく言うとshare/net shareコマンド
伝送手順の仕様（NetBEUI/NBT）

でも一番効いてそうなのは、
ファイル共有時の排他の粒度なのかな。
どの程度の広さの排他なのかが不明なんだけど。

read.cgi ver5.26+ (01/10/21-)