2005年11月27日

中の人のアドバイスもあったおかげでメモリ消費量を抑えることが出来ました。
現在は、通常通り安定してます。
適切に動かしてればsenna+MySQLは超安定してますから。ほんとに。

インデックスファイル

.sen.iファイルの初期サイズ
デフォルトでは130MBを確保しますが、設定ファイル(/var/senna/senna.conf)に、

INITIAL_N_SEGMENTS 数値のように数値を指定すると、

数値 * 256KBのサイズが確保されるようになります。

ただし、INITIAL_N_SEGMENTSの値を小さく設定するほど、更新処理の速度が低下しますので、デフォルト値よりも極端に小さい値を設定しない方が無難です。(デフォルト値は512です)


これを、128にしました。
デフォだとSEN.iに130MBくらい取られるけど、38MB位まで落とし込みました。
indexerの性能よりも動かないとしょうがないしね。
DBに使用するファイルサイズも半分程度になりました。

ただし、当然なんですが

インデックスのサイズ
hoge.SEN.iファイルはインデックス作成時に固定サイズを確保しますが、その後文書を大量に登録するとインデックスファイルの総サイズは、単語インデックスなら文書の賞味サイズの1.3倍程度、 n-gramインデックスなら文書の賞味サイズの2.5倍程度になります。

って事なので、データサイズが増えると結局メモリを食うという感じなのかなんなのか
メモリ消費量はINITIAL_N_SEGMENTSの値に影響するのかSEN.iファイルサイズに影響するのか、まだ分かってませんです。


1GB位のデータを1テーブルでfulltextしてたんだけど、1クエリあたり0.3秒もかかって使い物にならなかったの。
どうして使い物にならないかというと、1queryあたり10回sennaにクエリを投げなきゃいけなくて実質3秒もかかる感じだった。
そんなわけでテーブルを分割しまくって数十倍くらいパフォーマンス上がったところで、今回の現象に遭遇したと言う訳。

word indexだけmmapして、wordとdocidの対応表はmmapしないでキャッシュはOSに任せてしまう方式に改造したら
メモリ食わないけど、やっぱ劇遅になるのかなぁ。

今後index size増やす方向にもってくから、どうにかしないと。
てか複数台構成にしろって話。

Posted by Yappo at 2005年11月27日 13:52 | TrackBack | 検索システム構築
Comments
Post a comment









Remember personal info?






コメントを投稿する前に↓の場所にnospamと入力してください。