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

[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）

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

[286:名無しさん＠お腹いっぱい。 (02/02/16 14:42)]
>>284
・そのマシンに平均何人くらいから同時にアクセスがかかるか
・そのマシンの１つのファイルに平均何人くらいから同時にアクセスがかかるか
・1人あたり平均どのくらいの大きさのファイルを読むか/書くか
を想定すれば、ある程度計算で求められるかも。

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