寺西です。 [EMAIL PROTECTED] 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) [EMAIL PROTECTED] 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 mailing list Namazu-users-ja@namazu.org http://www.namazu.org/cgi-bin/mailman/listinfo/namazu-users-ja
