[Namazu-users-ja 826] Re: namazu/namazu.cgiで core-dump

Tadamasa Teranishi yw3t-trns @ asahi-net.or.jp
2006年 9月 14日 (木) 17:53:38 JST


寺西です。

taguchi @ iij.ad.jp wrote:
>  
> > となり、問題はありませんでした。
> > core ダンプする理由はもう少し条件が必要なのかもしれません。
> 
> うーん、ちょっと厭んな現象を持ち込んでしまったかもしれません_o_

何らかの条件が重なった場合に core ダンプするのでしょう。
core ダンプしない場合であっても、どこかでメモリを壊している可能性が
ありますので、できれば原因を突き止めてデバッグしたいものです。

現在 2.0.17 リリースの準備中ですので、この問題に対応したものを
リリースしたいものです。

> > インデックスに含まれる「日本」や「の」の数はどれくらいかわかりますか?
> 
> 調べました。
>         日本 : 10714
>         の   : 34318
>         歴史 :  1437
> でした。

このぐらいの数がひとつの条件となるのかもしれませんね。
私がテストしたのは2件程度のものですから。
 
> > そのインデックスが壊れている可能性はないでしょうか?
> > nmzchkw.pl で一度チェックしてみてください。
> 
> ここで初めて、nmzchkw.plの存在を知りました。ごっつい便利ですね。

NMZ.w と NMZ.wi の整合性を簡単にチェックするものです。
(次の Namazu 2.0.17 では contrib に入る予定です。)

このチェックが通ったとしても、インデックスが壊れていないとはいえない
のですが、NMZ.w, NMZ.wi についてはほぼ問題がないといえるでしょう。

本件の場合は、NMZ.i, NMZ.ii が壊れている可能性もありますが、
FreeBSD ということで BSD 関係の問題かもしれません。
(過去に BSD 関係でメモリ関連の問題が多少見つかっていまして、原因不明
なので対処療法的な対策を行っています。)

> > また、インデックスを削除して新規にインデックスを作成した場合でも
> > 同様に問題が起きるでしょうか?
> 
> これは、現在試している最中です。総文書数が4万件以上あり、今、3万件
> 目まできた所です。
> 多量のPDFが含まれているので、処理にごつい時間が掛かるです。

余談ですが...

$ON_MEMORY_MAX を相当大きな値にすると時間が短縮されるかもしれません。
(この値は、実メモリサイズと無関係なので、実メモリサイズを超えても
何ら問題ありません。)

また、ディレクトリ単位等でインデックスを分けて作成し、最後に
nmzmerge でマージするとトータル時間は短縮されるでしょう。
-- 
=====================================================================
寺西 忠勝(TADAMASA TERANISHI)  yw3t-trns @ asahi-net.or.jp
http://www.asahi-net.or.jp/~yw3t-trns/index.htm
Key fingerprint =  474E 4D93 8E97 11F6 662D  8A42 17F5 52F4 10E7 D14E




Namazu-users-ja メーリングリストの案内