Namazu-users-ja(旧)

[knok@xxxxxxxxxxxxx (NOKUBI Takatsugu)]

<200011140851.RAA06771@xxxxxxxxxxxxxxxxxxxxxx>の記事において
sato@xxxxxxxxxxxxxxxさんは書きました。
>> 佐藤です。
>> すみません。試しにmknmzの$ON_MEMORY_MAX   = 8000000として
>> インデックスを作り直したら、うまく表示されるようになってしまいました。
>> なんで？
>> その後10000000に戻して作成してみましたが、これもうまく作成されてしまいました。
>> まだ、公開はしていない環境なので、元の環境も削除してしまったし。失敗した・・・

  むむむ、そうでしたか。その状況から考えると、インデックスが正しく作成
されていなかった、という線があやしいですね。

>> >   完全に stack frame が壊れてるみたいですね。わざわざ試して頂いてあり
>> > がとうございます。
>> このstack frameが壊れているというのはどういうことでしょう？

  えーと、私にはきちんと説明できません ^^; ざっと探してみたら、
http://minatow3.aist-nara.ac.jp/oie-lab/person/eiji-ka/research/java/stack_machine/stack_frame/stack_frame.html
こんなページをみつけました。

  ともかく、今回の例ではどこかで壊れたインデックスを読みこんでしまい、
内部で不適切なポインタへのアクセスが発生してしまって stack frame が壊
れてしまった、ということだと思います。

>> 私の場合、作業が途中で止まっているような状態にはなっていませんでした。
>> 一応インデックスかされますが、標準で検索した場合、詳細を表示するところで
>> エラーになるということでした。対象のファイルはテキスト(htmlを含む)ですので、
>> 大容量ということはありません。

  最近あやしいなと思うのが、特に大容量のデータに対してインデックスを作
成した時のハードウェア側の不調です。
http://www.linux.or.jp/JF/JFdocs/GCC-SIG11-FAQ.html というような文章も
ありますし、postfix 方面でも FAQ でそういう問題の可能性について言及し
てたりします。
  まあ今回は大容量ではないとのことですが、そういう問題の可能性は常に考
えておいた方が良いと思います。なかなか見極めは難しいですが...

>> 参考までに教えて欲しいのですが、192MBではメモリの設定はどのくらいが適切な
>> のでしょうか？気のせいか、以前の表示文字数より、今回作り直したインデックス
>> のほうが少ないような気がします。というか、適度な場所で区切られている気がするなぁ。

  そういう所についてはちょっとわかりません... tune が必要な程のことを
したことがないので。

>> また、namazuの検索結果の詳細表示欄の文字数は変更できませんか？
>> 教えてください。

  これはちょっと無理ですね。ちゃんとやろうとするとマルチバイト文字の途
中で切ってしまわないような処理を含める必要があるので、なかなか大変そう
です。
  簡単なところでは、NMZ.field.summary を表示したい長さで切ってしまった
ものに書きかえる、という方法がとれると思います。
-- 
野首 貴嗣
E-mail: knok@xxxxxxxxxxxxx