namazu-ml(ring)

[Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>]

sugiura@xxxxxxxxxxxx (Sugiura Shiro) wrote:

>> v1.3.0.x の mknmz は対象ファイルのパス名のリストを全体まとめ
>> て配列に格納するので、ファイルが 75万個もあれば、それだけで
>> 大量のメモリを消費して当然です。
>
>当然っていわれてもこの件は初耳なのですが、特にperl側に問題があっ
>たというわけではないってことですね。

すみません。わたしの中では当然だったもので。対象ファイルのパ
ス名のリストを作るだけの簡単な処理にメモリをたくさん食うのは
ばからしいので、近いうちに改善しますね。


>Added Files: 878,914 files
>Total Files: 878,914 files
>Size: 2,167,480,108 bytes

これはすごい! 世界新記録です。 :-)
# ちゃんと検索できますよね?

さっそく FAQ を更新しておきました。
<http://openlab.ring.gr.jp/namazu/FAQ.html#INDEXSCALE>
(勝手に載せてしまいましたが、いいですよね?)


  ...

ところで、Namazu のインデックスは 32 bit 符合付き整数の壁が
あるので、

>NMZ.i	721295588

この約 687 Mb のファイルが 2Gb を越えると扱えなくなります。
同じようなファイルを対象にインデックスを作ると仮定して、単純
に計算すると、Namazuが扱える最大規模のインデックスは

  ファイル数: 2,048 / 687 * 878,914       =     2,620,110 (約262万)
  合計サイズ: 2,048 / 687 * 2,167,480,108 = 6,461,425,416 (約 6 Gb)

となります。この規模のインデックスを作るには相当たくさんのメ
モリ (2 Gbくらい?) を積んで $ON_MEMORY_MAX を 300 Mb くらい
に設定しないと (インデックス作成が遅くて) やっていられないと
思います。

# 細かい話: NMZ.i, NMZ.p を作成する部分の処理は非効率なので、
# 対象ファイルが多くなるにつれてどんどん遅くなっていきます
# (たびたび書き直すので、全体で O(n^2) の仕事量を要する)。 
# $ON_MEMORY_MAX の値を大きくすれば、NMZ.i, NMZ.p の作成の回
# 数を少なくできるので、その分、速くなります。ほかの部分の処
# 理は大体、線形なので対象ファイルの数に関わらず、ほぼ一定で
# す。(たぶん)

ちなみに、最新の実装では 1.4.0.8-beta-8 に比べて、 NMZ.i,
NMZ.p が 2-3割くらい小さくなっています。また、 NMZ.i とNMZ.w 
を統合して NMZ.i のサイズを小さくする計画もあるので、そうす
ると、もう少し規模の多いインデックスが作れるはずです。

# そんな巨大なインデックスを作る人はいないと思うけど。…と油
# 断してはいけないかな :-)

そんなわけで、Namazu 2.0 では、1.3.0.xとくらべて全体のインデッ
クスのサイズはおおよそ半分くらいになる見込みです。もちろん情
報の量は削らずに、です。(1.3.0.xのインデックスに無駄が多かっ
たからなんだけど ;-）

-- Satoru Takabayashi