高見 直輝
takam****@orega*****
2016年 7月 12日 (火) 18:40:33 JST
高見です。
> >> 念のための補足ですが、一度開くと今後は開いたテーブル・カラム
> >> を使いまわすので、上述のSELECT分を実行するごとにメモリー使用
> >> 量が増え続けることはありません。1回目のSELECT分で増え、それ
> >> 以降は一定です。（一時的に確保するメモリーはありますが、それ
> >> らは処理が終わったら開放します。）
> >
> > この"一定のメモリ使用量"は、テーブルのレコード数によって増加するのでしょ
> > うか？それとも、レコードに登録されている文字列の合計サイズによって増加す
> > るのでしょうか？
>
> どちらでも増加しえます。わかりやすい確認方法は、*.pgrn.*ファ
> イルが増えたら増加したという感じです。
インデックスのデータ量が一定値を超えるとpgrnファイルが増加するということ
でしょうか？
そうであれば、増加するときのファイルサイズを教えてください。
※増加するときのレコード数を、ある程度把握する必要があるためです。
> > "メモリー上にだけある変更“の総量はGroongaデータベースを変更した量（又は
> > 回数）に比例すると思っていました。
>
> だいたいはそれであっています。
> OSが自動的に変更をディスクに書き出すこともあるため、それが動
> いた時は比例しません。
>
> > OSが自動的に書き出す処理は、io_flushを引数無しで実行したものと同じ、全テー
> > ブルの分を一括処理するものなのでしょうか？
>
> Windowsの内部の話なので確かなことはわかりませんが、一括処理
> ではないと思います。一部のみを書き出すということもあり得ると
> 思います。たぶん、一番効率のよい（と思われる）方法を使うと思
> います。
メモリが足りない環境下では、メモリを大量確保する選択肢は採られ難い、といっ
たところでしょうか。
> > 運用上、使われるテーブルが一部に限られる可能性は高いのですが、テーブル数
> > に上限が無い仕様となっているので、全テーブルに対してSELECTが実行されるも
> > のと考える必要があります。
> > ただ、検索が終わった後にテーブルを開いたままにしておく必要は無いので、テー
> > ブルを閉じることが出来るのであれば、プログラムによる対応も可能になります。
> > SELECTの実行後にquitコマンドを実行すれば良いのでしょうか？
>
> 確認していないのですが、
>
> SELECT pgroonga.command("database_unmap");
>
> で開いているテーブル・カラムをすべて閉じることができるので、
> これがよさそうな気がします。
io_flushコマンドの直前に実行してみましたが、特にメモリ使用量に変わりはあ
りませんでした。
> >> DDLを教えてもらえればどんなio_flushを発行すれば網羅できてい
> >> るかを伝えることができます。
> >
> > Sources〜に対して実行した後、データベースに対して実行してます。
> > 他に必要な処理はありますか？
>
> Sources*に対応するインデックスカラムとそれらのカラムに対する
> テーブルにもio_flushすれば大丈夫だと思います。
具体的には『Lexicon*』テーブルでしょうか？
-----------------------------
高見 直輝 <takam****@orega*****>
株式会社オレガ
TEL:03-3267-0150
FAX:03-3267-0180