Kouhei Sutou
kou****@clear*****
2016年 7月 13日 (水) 13:47:22 JST
須藤です。 In <20160****@orega*****> "[groonga-dev,04074] Re: io_flushが大量のメモリを確保する" on Tue, 12 Jul 2016 18:40:33 +0900, 高見 直輝 <takam****@orega*****> wrote: > インデックスのデータ量が一定値を超えるとpgrnファイルが増加するということ > でしょうか？ 細かく言うと違うのですが、大体そのような感じです。 > そうであれば、増加するときのファイルサイズを教えてください。 pgrnファイル1つは最大1GiBです。それより大きくなった場合は新 しくpgrnファイルを作ります。 > ※増加するときのレコード数を、ある程度把握する必要があるためです。 1つのpgrnファイルでもデータ量が増えると徐々にファイルサイズ が増えていきます。（多くの場合は4KiBずつ増えていきます。） 実際にデータを追加しながらどのくらいのペースで増えるか確認す るのがよいと思います。データによってファイルサイズが増えるペー スは異なるからです。 >> Windowsの内部の話なので確かなことはわかりませんが、一括処理 >> ではないと思います。一部のみを書き出すということもあり得ると >> 思います。たぶん、一番効率のよい（と思われる）方法を使うと思 >> います。 > > メモリが足りない環境下では、メモリを大量確保する選択肢は採られ難い、といっ > たところでしょうか。 Windowsの内部の話なので実際のところはわかりませんが、そうだ といいなぁと私は思っています。 >> 確認していないのですが、 >> >> SELECT pgroonga.command("database_unmap"); >> >> で開いているテーブル・カラムをすべて閉じることができるので、 >> これがよさそうな気がします。 > > io_flushコマンドの直前に実行してみましたが、特にメモリ使用量に変わりはあ > りませんでした。 実際にやってみると [ [ -2, 1468384856.115391, 0.003027439117431641, "[database_unmap] the max number of threads must be 1: <0>", [ ["proc_database_unmap", "proc.c", 3201] ] ], false ] と返ってくるのでPGroongaでdatbase_unmapを使える設定になって いないだけですね。 次のリリースからは使えるようにしておきます。 >> Sources*に対応するインデックスカラムとそれらのカラムに対する >> テーブルにもio_flushすれば大丈夫だと思います。 > > 具体的には『Lexicon*』テーブルでしょうか？ 「Lexicon*」テーブルとそれらのテーブル内にあるカラムです。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> 10周年祝いイベント： http://www.clear-code.com/blog/2016/7/13.html Groongaベースの全文検索システムを総合サポート: http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス: http://www.clear-code.com/recruitment/
