2006年10月26日

[Namazu-devel-ja 1329] Re: mknmz の処理時間短縮

寺西です。

Yukio USUDA wrote:
>
> > $ON_MEMORY_MAX は、その変数名から想像するようなメモリサイズとは
> > 何ら関係ありません。当然、物理メモリサイズとの因果関係は何も
> > ありません。
>

> ・シェルで設定されたユーザーメモリ利用の制限値を超えると
> Perl が止まる
> ・対象ファイル数が多い際に Perl のスタック?が溢れ
> Perl が止まる
> ・上記の2件を防止するために連続して読み込んだファイルサイ
> ズの合計が
>  $ON_MEMORY_MAX に達したところで一時書き出しをしている。

これは中間ファイルを書き出すだけでは何の効果もありません。

何故なら中間ファイルを書き出しただけでメモリはフリーしませんから
処理するデータ量が多ければ、中間ファイルを書き出そうが、出さまいが
一切関係なく破綻します。
主メモリが大きければより大きなデータを取り扱うことができますが、
それと $ON_MEMORY_MAX の値に何の関係もありません。

--checkpoint を付けた場合には、exec し直すので、メモリリークがあった
場合に意味はありますが、それもデバッグ用途の域を出ません。

破綻した場合に残される中間ファイルの完成度は頻繁に書き出しを行った
方が高いのは確かですが、一般に中間ファイルを再利用する有効な
方法はありませんので、それもほとんど意味のないことです。

全く中間ファイルを残さないのが良いとは思いませんが、現状のような
頻度で残す必要はないでしょう。

> 物理メモリサイズが増えてきているのを前提として OS, シェル,
> Perl 等
> の初期設定値も昔とは変わってきているのではないでしょうか。

というよりは、Namazu で処理するデータ量が想定よりもはるかに
多くなっているということでしょう。

また、様々な用途に使われるので、デフォルトとして最適な値というもの
を決定できなくなったという背景もあるでしょう。

> そもそも $ON_MEMORY_MAX の値は Out of Memory 症状の
> 原因との
> 因果関係は少ない経験値のようなものです。

そうですね。

> 本当は、中間ファイルをマージしないでどんどん別ファイルとして保存し
て、
> 最期にマージするのがいいんですけどね...
> 昔からやろうやろうと思っていてできていない改良のひとつです。

中間ファイルを書き出してメモリを解放し、最後にマージする場合は
ファイルの書き出しに関しては O(n) に近づくので速度はぐんと速く
なるでしょう。
ただ、最後にマージする部分で現状の nmzmerge のような方法でマージ
すると、データサイズが大きい場合にはメモリに載りきらずにエラーに
なるので、消費メモリの少ないマージ方法を考えることも重要になって
くるでしょう。

その辺りを考えると現状のインデックスのフォーマットには大きな問題が
あるので、フォーマットの設計をやり直したいわけです。
--
=====================================================================
寺西 忠勝(TADAMASA TERANISHI) yw3t-trns@xxxxx
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint = 474E 4D93 8E97 11F6 662D 8A42 17F5 52F4 10E7 D14E

_______________________________________________
Namazu-devel-ja mailing list
Namazu-devel-ja@xxxxx
http://www.namazu.org/cgi-bin/mailman/listinfo/namazu-devel-ja

投稿者 xml-rpc : 2006年10月26日 09:08
役に立ちました?:
過去のフィードバック 平均:(0) 総合:(0) 投票回数:(0)
本記事へのTrackback: http://hoop.euqset.org/blog/mt-tb2006.cgi/48342
トラックバック
コメント
コメントする




画像の中に見える文字を入力してください。