sakamoto
sakam****@ma*****
2007年 12月 27日 (木) 20:36:00 JST
坂本です。 幸坂さん、ありがとうございます。 後半部のバグの件、SQLの組み方にも問題があるので、 そこは修正したいと考えていますので、致命的な問題には なっていないのですが、 前半部の明示的にSennaインデックスを解放する方法が無いのは、 残念でした。 プロセスを落とさなくとも、接続を切れば良いということであれば、 こちらサイドで対応できるかなということで、手を入れてみたいと 思っています。 よろしくお願いいたします。 > 幸坂です。こんにちは。 > >> また、この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 >> > > _______________________________________________ > Ludia-users mailing list > Ludia****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/ludia-users
