【PINKちゃんねる】新サーバ獲得会議☆2

このエントリーをはてなブックマークに追加
419動け動けウゴウゴ2ちゃんねる
>>410
細かいファイルを大量に扱う処理って事を考えると、
ディスクアクセスのシーク待ちとか、結構大きいと思う。

たとえば平均シークタイム10msとすると、
1秒間に100以上のファイルには原理的にアクセス不可能だし。
まぁ、ここら辺の都合はシステムのディスクキャッシュ容量と方法に
依存する部分も多いわけだが。
420動け動けウゴウゴ2ちゃんねる:04/02/17 14:26 ID:QXF8TMLt
>419
それは全く同意。

どっか別のスレでroot氏が
「256KBと512KBのファイルの差はそれほど大きくない(openの負荷と比較して)」
と言っていたけど、それは違うと思う。
もちろん、openでディレクトリをシーケンシャルに探索するのも結構手間だけど
softupdateを使うと、原理上必ずフラグメントが発生するし、
softupdateでなくても、少量づつ追記するシステムは必ずフラグメントの問題が出る。

仮にシーク4ms,15Krpmだとすると、
シークに4msと平均回転待ちで2ms、1ブロックにアクセスするのに合計6ms使う。
1ブロック16Kだと、256Kでは16回のディスクアクセスで約0.1秒の差が出る。
下手をすると、bbs.cgiでは追記しないで全部一括して書き込んで
連続したセクタを読み込ませた方が早いということになりかねない。

というのが理論上だけど、
実際には、ディレクトリエントリも、.datの内容も大半がOSにキャッシュされるので
物理ディスクにアクセスするのは書き込み時が殆どで
読み込みだけなら、どの程度の割合でディスクアクセスが発生するのかが問題になる。
これがわからない。
また、bbs.cgiでは、read.cgiとは比較にならない数のファイルに書き込むので
read.cgiでの差はあまり大きくないという可能性もある。

FreeBSD鯖(ufs)では、noatimeでなければ、最終アクセス時を必ず記録しに行くし、
apacheがログを取って(バッファリングしていなければ)入れば、必ずそれを書き込みに行く。
ただ、linux鯖(ext2/3)だと、async書き込みの上、
書き込み順序も決まっていない(物理的に近いセクタの書き込みを優先する)ので
この限りではないらしい。

ま、とにかく物理的に読み込む比率がわからないと判断しようがない。
(メモリ量的には、過去ログ以外の全てキャッシュを納められる程度の量はあるはず)