namazu-dev(ring)

[Satoru Takabayashi <satoru-t@xxxxxxxxxxxxxxxxxx>]

藤原  誠 Makoto Fujiwara <makoto@xxxxx> wrote:

>satoru-t> 改善案では進捗状況がよくわかります。おおよその終了時間を予測
>satoru-t> できるため、利用者は安心すると思います。
>
>僕は、これがとてもいいと思って、そういう意見を書いたつもりでしたが、
>思っただけで何も手が動いていませんでした。ごめんなさい。とてもいい
>と思います。

というわけで、変更して commit しました。こんな感じです:

  % mknmz -a /tmp/foo
  9個のファイルがインデックス作成の対象として見つかりました
  1/9 - /tmp/foo/1 [message/rfc822]
  2/9 - /tmp/foo/2 [message/rfc822]
  3/9 - /tmp/foo/3 [message/rfc822]
  4/9 - /tmp/foo/4 [message/rfc822]
  5/9 - /tmp/foo/5 [message/rfc822]
  6/9 - /tmp/foo/6 [message/rfc822]
  7/9 - /tmp/foo/7 はサイズが 0 なので無視します
  7/8 - /tmp/foo/8 [message/rfc822]
  8/8 - /tmp/foo/9 [message/rfc822]
  インデックスを書き出しています...
  [基本]
  日付:                Tue Feb 15 12:28:12 2000
  追加された文書の数:  8
  サイズ (bytes):      19,163
  合計の文書数:        8
  追加キーワード数:    570
  合計キーワード数:    570
  わかち書き:          module_kakasi -ieuc -oeuc -w
  経過時間 (秒):       12
  ファイル/秒:         0.67
  システム:            linux
  Perl:                5.00503
  Namazu:              1.9.14


>ついでなのですが、ちょっと関係ありそうな記憶領域の使用量のことです。
>僕の感触では 30kbytes/file という気が何とはなくしていて、
>例えば 1000 file だと 30M, 3000 file だと 90M というような目安を持っ
>ているのですが、合っているでしょうか。もしそうだとしても、
>人に言えるような有意な数字でしょうか。
(snip)
>とは言っても本当に大雑把な話です。当然一つ一つの大きさにも依るでしょ
>うし。僕は以上では通常のメールのことを考えています。
>また OS にも依るでしょうか。

いろんな条件によって変わります。mknmz は mknmzrc の 
$conf::ON_MEMORY_MAX の値で、メモリに読み込む文書ファイルの
量を制限しています。そして、読み込んだ文書ファイルの量が
$conf::ON_MEMORY_MAX に達するたびに、一時的にインデックスを
書き出しを行います。

そういった処理を行っているので、mknmz のプロセスのサイズはあ
る点で膨張が止まるはずです。しかし、現実にはじわじわと膨張し
続けてしまいます。

そこで、 -s オプションの登場です。

>それとも -s でこの辺は事情が変りますか。

-s を指定すると「一時的にインデックスを書き出し」のときに
mknmz が自分自身を exec し直します。このときに mknmz のプロ
セスのサイズはぐっと小さくなります。(生まれ変わる)

興味のある方は挙動を top で眺めてください。

# -s オプションのアイディアは、喜多淳一郎さんからいただきました

-- Satoru Takabayashi