Kouhei Sutou
kou****@clear*****
2016年 7月 11日 (月) 09:25:35 JST
須藤です。 In <20160****@orega*****> "[groonga-dev,04071] Re: io_flushが大量のメモリを確保する" on Thu, 07 Jul 2016 18:55:52 +0900, 高見 直輝 <takam****@orega*****> wrote: >> 念のための補足ですが、一度開くと今後は開いたテーブル・カラム >> を使いまわすので、上述のSELECT分を実行するごとにメモリー使用 >> 量が増え続けることはありません。1回目のSELECT分で増え、それ >> 以降は一定です。（一時的に確保するメモリーはありますが、それ >> らは処理が終わったら開放します。） > > この"一定のメモリ使用量"は、テーブルのレコード数によって増加するのでしょ > うか？それとも、レコードに登録されている文字列の合計サイズによって増加す > るのでしょうか？ どちらでも増加しえます。わかりやすい確認方法は、*.pgrn.*ファ イルが増えたら増加したという感じです。 > "メモリー上にだけある変更“の総量はGroongaデータベースを変更した量（又は > 回数）に比例すると思っていました。 だいたいはそれであっています。 OSが自動的に変更をディスクに書き出すこともあるため、それが動 いた時は比例しません。 > OSが自動的に書き出す処理は、io_flushを引数無しで実行したものと同じ、全テー > ブルの分を一括処理するものなのでしょうか？ Windowsの内部の話なので確かなことはわかりませんが、一括処理 ではないと思います。一部のみを書き出すということもあり得ると 思います。たぶん、一番効率のよい（と思われる）方法を使うと思 います。 > 運用上、使われるテーブルが一部に限られる可能性は高いのですが、テーブル数 > に上限が無い仕様となっているので、全テーブルに対してSELECTが実行されるも > のと考える必要があります。 > ただ、検索が終わった後にテーブルを開いたままにしておく必要は無いので、テー > ブルを閉じることが出来るのであれば、プログラムによる対応も可能になります。 > SELECTの実行後にquitコマンドを実行すれば良いのでしょうか？ 確認していないのですが、 SELECT pgroonga.command("database_unmap"); で開いているテーブル・カラムをすべて閉じることができるので、 これがよさそうな気がします。 >> DDLを教えてもらえればどんなio_flushを発行すれば網羅できてい >> るかを伝えることができます。 > > Sources〜に対して実行した後、データベースに対して実行してます。 > 他に必要な処理はありますか？ Sources*に対応するインデックスカラムとそれらのカラムに対する テーブルにもio_flushすれば大丈夫だと思います。 >> 「SELECT pgroonga.flush("INDEX_NAME")」とすれば大丈夫になるよ >> うな関数を提供するのがいい気がしてきました。 > > そうですね。現状プログラムでインデックス名からのGROONGAテーブル名（Sources〜） > を取得するSQLを発行する必要があるので、このコストが省けるようになるのは > 大きいと思います。 ですよね。 その方向で検討します。 > 書き込み途中のデータについては、破損の可能性を0にすることは出来ないと考 > えています。 はい、その通りです。 > ドキュメントのload と deleteの書き出し対象を見ると、データベースが対象に > 含まれていないので、破損した場合このテーブルに対するREINDEXだけで回復で > きるのではありませんか？ これもそのとおりです。 > 書き出すデータの量と、確保するメモリの量に相関関係はあまり無いということ > ですね。 はい、そのとおりです。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> 10周年祝いイベント： https://clear-code.doorkeeper.jp/events/48646 Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/
