sakamoto
sakam****@ma*****
2007年 12月 26日 (水) 15:02:10 JST
こんにちは、坂本です。 下記の件、追加検証してみました。 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
