Hyper Estraier : P2Pを試してみた

HyperEstraierのP2Pガイドに従って試してみたので、めも。

 

とりあえず、試したのはWindowsPC１台のみの環境で、

P2Pガイドに従い文書ドラフト(.est)ファイルを用意して読み込ませる方法を試した。

 

実際に試してみて、生成されたフォルダを確認してみたところ、

casket\_node\data001

 

というフォルダ構成になっていて、data001の中を覗いてみると、

なにやら見覚えのあるファイルが。　

 

そこで、既存のHyperEstraierのインデックスファイルを、

P2P用に生成されたフォルダに上書きしてみたら、普通に使えました。

 

そこで次のステップとして、前回ハマッタ1600万件以上のインデックスを

100万件ごとに区切ったインデックス、20個をP2Pに食わせてみました。

 

その結果、やっぱり fetal error : out of memory　で落ちた。

 

インデックスが1600万件を超えるような場合では、

PCを複数台用意してインデックスを分けてやる必要がありそうです。

 

今日の収穫は、

P2P用のインデックスフォルダにHyperEstraier用のインデックスが

そのまま流用可能だと分かったこと。

 

やっぱりPC複数台用意するしかないかぁ...

Hyper Estraier : fatal error out of memoryの調査

約100万件のインデックスを20個ほど個別に生成したものを、

estcmd mergeでひとつのインデックス（合計2000万件）にまとめようとしたところ

fatal error out of memoryで落ちてしまう件の調査。

 

現象としては、16個のインデックスをマージしている最中、

wnum（語句？）の登録の１回目で落ちる。

 

使用しているアプリは、公式版 windowsバイナリ1.4.10のもの。

 

HyperEstraierから呼び出しているQDBMのDLLでエラーが出ているらしい。

ということまでは先日の調査で分かっている。

 

ふと、HyperEstraier最新版の1.4.13で試したらどうなのかな？と。

 

やってみた結果、やっぱり落ちた。

 

落ちた時点でのマージ途中のインデックスフォルダのサイズは約10GB

 

estcmd repairで復旧を試みるも、こちらもやはり

fetal error : out of memory と出て落ちる。

 

ソースコード確認してもmalloc()でメモリ確保してるところでこけているらしい。

メモリは十分に空いてるのに...なぜ？

 

最初からマージしていると、現象が再現するまでに１０時間とかかかるので、

とりあえず、手っ取り早く現象を再現させる方法を考えないと。

Hyper Estraier : estcmd merge で fatal error out of memory発生

約1800万件程度のデータベースを作りたくて試行錯誤。

 

ひとつのデータベースサイズを約100万行で区切って生成し、

それを、estcmd mergeでひとつにまとめるという目論見だったが、見事に玉砕。

 

1500～1600万件ほどのマージに差し掛かったところで、

fatal error out of memory を吐いていて、バッチ処理が止まってた。

 

サイズに上限があるのかしら？

 

1000万件と800万件のデータベースに分けて、ユーザーに使い分けてもらう...

というのは論外なので、Hyper EstraierのP2Pというものを試してみようと思う。

 

P2Pの説明によると、100万件のデータベースを10個用意して、

1000万件のデータベースとして扱える...と書いてあって、期待が持てる。

 

いやぁ～休日前にバッチ処理仕込んでおいて、休み明けにデータベースできてるかなぁ～とワクワクしながら職場に行ったらfaltal error で落ちてるとか、涙目でした。

Hyper Estraier : 自作gatherで異常終了する件の調査

自作gatherで1GB程度のファイルリストを読み込むと、半分くらい処理したところで

fetal error吐いて落ちる件、どうにも腑に落ちないので調べてみた。

 

エラーを吐いている箇所は、

HyperEstraierのDLLから呼び出している、

QDBMというデータベースを制御する別のDLL内部だと言うところまでは分かった。

 

でも、そこまでしか分からず。

 

とりあえず、先日の出力データベースファイルを小分けにする対策で

やりたいことは出来ているので、しばらく様子を見てみることにした。

Hyper Estraier : gather っぽいものを作ってみた。

思うところがあって、gather 機能的なものを作ってみたので、その記録。

 

文書ドラフト(.est)ファイルを1000万件（ファイルサイズは1kB程度）ほど、作って、

estcmd で読み込んでデータベースを作ろうとしたんだけれども、

1000万件分の文書ドラフトファイルを生成する処理だけで、数日かかりそうなことが分かって、別の方法がないかなと。

 

元ネタファイル→文書ドラフト(.est)→Hyper EstraierのDBファイル。

としたかったが、文書ドラフト(.est)を作るのをやめて、

元ネタファイル→Hyper EstraierのDBファイルと出来ないかな？　と。

 

WindowsバイナリのHyper Estraier 1.4.10をダウンロードして、

そこに含まれているDLLを拝借して、オレオレgather的なものを作ってみた。

 

gatherの作り方は、プログラミングガイドのサンプルコードを拝借。

http://fallabs.com/hyperestraier/pguide-ja.html

 

速度は文書ドラフトを作らないだけあって速い。

実際に動かしてみると、元ネタのファイル1GBを半分くらい

（ドラフト文書相当数だと、だいたい220万件程度を）処理したところで

> fatal error : memory corrupt

とか出てきてアプリが落ちた。

 

メモリ使用量は、500MBくらいで、4GBのメモリの3GB以上空いている状態。

原因はメモリ不足ではなさそう。

 

原因追求する時間が惜しかったので、とりあえず入力ファイルを小さく分割して、

それぞれに対応する小さなデータベースファイルを出力するようにしたら無事最後まで処理完了。　

 

あとは、Hyper Estraier付属のestcmd.exeで

複数のデータベースをマージしてひとつの巨大なデータベースにするだけ。

 

途中でハマって処理方法を変えたので、自作アプリを作り直すはめになったけど、

当初の目的が何とか達成できましたとさ。　

 

Hyper Estraierはドキュメントが充実していて、ほんとうにありがたいです。

Hyper Estraierのフォーム

フォームのメモ

付属のestseek.confファイル中の

formtype: nomal

と書いてある箇所を、

formtype: file

とか、

formtype: web

と、変更するとフォームが変わります

 

formtype: nomal　とした（標準）フォーム↓

f:id:jet_lag_htb:20150809182912j:plain

 

formtype: file　としたフォーム↓（body text, file pathボタンが増えている）

f:id:jet_lag_htb:20150809182902j:plain

 

formtype: web　としたフォーム↓（titleボタンが増えている） f:id:jet_lag_htb:20150809183031j:plain

 

ほんと、Hyper Estraierって至れり尽くせり感が凄い。