kousa****@nttda*****
kousa****@nttda*****
2007年 12月 27日 (木) 14:26:21 JST
幸坂です。こんにちは。 > また、この16個をまとめてViewにして検索したところ、予想通り、 > max_n_index_cache=5の時は、 > ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small １クエリ内でmax_n_index_cacheより多くのインデックスを利用すると、 エラーとなります。 この事象については、改良しようと思っているのですが、 max_n_index_cacheを大きくするという解決方法があり、 改修範囲も大きい事から、優先順位を下げています。 しかし、坂本さんの例もあるので、考え直した方が良さそうですね。 検討します。 > なりそうなのですが、そのように、明示的にsennaインデックスを > 解放する方法はあるでしょうか。 現状、明示的にSennaインデックスを解放する方法はありません。 接続を切れば解放できますが・・・。 > 同一インデックスでも、同一SQLで2度登場する場合、別カウントされている > ということになるでしょうか？ バグが存在しました。 1クエリ内で使用するインデックス数＝max_n_index_cacheで、 かつ、1クエリ内で同じインデックスを２回以上使用すると、 このバグが発生する場合があります。 WHERE col2 @@ '黒' AND col2 @@ '白'; のように、 単純にANDやORで繋げた場合は発生しません。 Ludiaの次のバージョンで修正します。 現状では、max_n_index_cacheを1大きい値(今回の場合17)に設定すると、 エラーにならないはずです。 以上です。 > -----Original Message----- > From: ludia****@lists***** > [mailto:ludia****@lists*****] On Behalf > Of sakamoto > Sent: Wednesday, December 26, 2007 3:02 PM > To: ludia****@lists***** > Subject: [Ludia-users 163] Re:データ投入時にメモリ確保エラー > > こんにちは、坂本です。 > > 下記の件、追加検証してみました。 > > max_n_index_cacheを5に変更してみたところ、インデックスがこの数を > 越えると解放しているようで、評価予定の件数(50万件）を > 格納することができました。 > この時、sennaのインデックスは16個できていました。 > > また、この16個をまとめてViewにして検索したところ、予想通り、 > max_n_index_cache=5の時は、 > ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small > でエラーになり、 > max_n_index_cache=16に設定すると、検索は正常終了しました。 > > ということから判断すると、１プロセスからのインデックス作成時に、 > sennaのインデックスを解放しながら実行できれば、何とか > なりそうなのですが、そのように、明示的にsennaインデックスを > 解放する方法はあるでしょうか。 > > それと、もう一点、気になった点があるので、確認させていただきたいのですが、 > > SELECT col1 FROM V_View WHERE col2 @@ '黒' ; > （V_Viewは同一フォーマットの表を16表を結合している） > はmax_n_index_cache=16で検索できましたが、 > SELECT col1 FROM V_View WHERE col2 @@ '黒' INTERSECT > SELECT col1 FROM V_View WHERE col2 @@ '白' ; > はmax_n_index_cache=16では > ERROR: pgsenna2: inconsistent scan, or max_n_index_cache is too small > のエラーとなり、max_n_index_cache=32 では正常終了しました。 > 同一インデックスでも、同一SQLで2度登場する場合、別カウントされている > ということになるでしょうか？ > > > > > 坂本です。 > > > > 幸坂さん、ありがとうございます。 > > > > COMMITを切っても、sennaのインデックスは > > 解放されないということですね。 > > > > 該当環境では、max_n_index_cacheを105に設定変更しています。 > > というのも、１インデックスが2Gを超えるとエラーになるので、 > > 分割するようにしたのですが、参照する際には、それらを > > Viewを使って参照しているので、同時にsennaのインデックスを > > オープンする数が増えるなあ、ということで。 > > > > お話からすると、今回のケースでは、12個目のインデックスで > > エラーになっているので、それ以下に設定すれば、投入時の > > エラーは回避できるかも知れませんが、 > > 参照時にmax_n_index_cacheのために同時にオープンできなくて、 > > または、max_n_index_cacheを増やしても、今度は、1プロセスの > > メモリ取得でエラーになりそうな雰囲気ですね。 > > > > 現在、該当環境が無いので、参照系の確認ができず、 > > 歯がゆいのですが、まず、max_n_index_cacheの設定変更で > > どうなるかの確認は行いたいと思います。 > > > > > >> 幸坂です。こんにちは。 > >> > >> 1プロセスのメモリ使用量が原因かもしれません。 > >> max_n_index_cacheを小さい数字にすると、 > >> 問題が解決する可能性があります。 > >> > >> max_n_index_cacheは1プロセスが開けるインデックス数です。 > >> この値を超えてインデックスオープンを試みると、 > >> LRU方式でインデックスをクローズし(sen_index_close)、 > >> Sennaのメモリを解放します。 > >> > >> 以下の内容も参考にしてください。 > >> > http://lists.sourceforge.jp/mailman/archives/ludia-users/2007- > October/000110 > >> .html > >> > http://lists.sourceforge.jp/mailman/archives/ludia-users/2007- > October/000123 > >> .html > >> > >>> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 > >> エラーにより接続が切れて、全てのメモリが解放されたため、 > >> 正常に動作していると思われます。 > >> > >>> -----Original Message----- > >>> From: ludia****@lists***** > >>> [mailto:ludia****@lists*****] On Behalf > >>> Of sakamoto > >>> Sent: Tuesday, December 18, 2007 2:02 PM > >>> To: ludia****@lists***** > >>> Subject: [Ludia-users 157]データ投入時にメモリ確保エラー > >>> > >>> こんにちは、坂本です。 > >>> > >>> Windows上で、次のようなシーケンスで大量にデータ投入を行っています。 > >>> （Ludia1.2＋senna1.0.8） > >>> > >>> １．全文検索インデックス１個を持った表１へデータを順次投入します。 > >>> ２．インデックスサイズが約512MB近くになると、表１への > >>> データ投入を終了し、同一の構造を持った表２を作成し、 > >>> 表２へデータ投入を続けます。 > >>> ３．表２もインデックスサイズが約512MB近くになると、次に > >>> 表３を作成し、表３へデータ投入を続けます。 > >>> ４．このように１表の（１インデックスサイズ）をある程度抑えて、 > >>> 順次表を追加していく形で大量データの投入を試みています。 > >>> > >>> ※１インデックスが２GBを超えると、メモリ確保できずにエラーと > >>> なる件がありましたが、それを回避するために表を分割しています。 > >>> また、１インデックスが１GBを超えると更新時の性能が出ない > >>> こともあり、切り替えの設定を低めにしています。 > >>> > >>> 本処理を実行し続けると、途中で、エラーで落ちます。 > >>> 実際のSQLシーケンスとしては、 > >>> BEGIN → INSERT （100件程度）→ COMMIT > >>> を繰り返しています。 > >>> > >>> Ludiaログの内容は、次の通りです。 > >>> > >>> 2007-10-24 04:40:42 LOG: pgsenna2: |A| malloc fail > >>> (76836502)=00000000 > >>> (..\lib\inv.c:922) <9617> > >>> 2007-10-24 04:40:42 ERROR: pgsenna2: sen_index_upd failed > >>> while do_insert > >>> (1) > >>> 2007-10-24 04:40:42 STATEMENT: INSERT INTO T_CSV_000012 > >>> (SMGSEQ, PAGENO, > >>> DATA) VALUES(502724, 1, ' > >>> > >>> Ludia1.3.1でメモリの解放に関する修正を行ったということで、 > >>> これも確認しましたが、同じ場所で、同様に落ちます。 > >>> > >>> 2007-10-27 14:09:12 LOG: pgsenna2: |A| malloc fail > >>> (76836502)=00000000 > >>> (..\lib\inv.c:922) <9619> > >>> 2007-10-27 14:09:12 ERROR: pgsenna2: sen_index_update failed 1,0 > >>> 2007-10-27 14:09:12 STATEMENT: INSERT INTO T_CSV_000012 > >>> (SMGSEQ, PAGENO, > >>> DATA) VALUES(502724, 1, ' > >>> > >>> 少なくとも、COMMIT時にメモリも解放されて問題なく動作すると > >>> 考えているのですが、１APから実行することによる弊害があるのでしょうか。 > >>> 合計は２GBを優に超えています。 > >>> > >>> ちなみに、エラー後、以降の処理を再実行すると正常に格納されます。 > >>> > >>> 何か考えらること、良い対応方法は無いでしょうか。 > >>> > >>> _______________________________________________ > >>> Ludia-users mailing list > >>> Ludia****@lists***** > >>> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > >>> > >> > >> _______________________________________________ > >> Ludia-users mailing list > >> Ludia****@lists***** > >> http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > > > _______________________________________________ > > Ludia-users mailing list > > Ludia****@lists***** > > http://lists.sourceforge.jp/mailman/listinfo/ludia-users > > _______________________________________________ > Ludia-users mailing list > Ludia****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ludia-users >
