高見 直輝
takam****@orega*****
2016年 7月 13日 (水) 15:54:43 JST
高見です。
> > インデックスのデータ量が一定値を超えるとpgrnファイルが増加するということ
> > でしょうか？
>
> 細かく言うと違うのですが、大体そのような感じです。
>
> > そうであれば、増加するときのファイルサイズを教えてください。
>
> pgrnファイル1つは最大1GiBです。それより大きくなった場合は新
> しくpgrnファイルを作ります。
>
> > ※増加するときのレコード数を、ある程度把握する必要があるためです。
実際に試してみました。
1GBで新しいファイルが作られた時点でio_flushを実行したところ、テーブルが
空のときと比較して、使用されるメモリの容量に違いは見られませんでした。
※双方共に60MB程度。
ファイルの増加によるメモリ使用量の変更は、それほど大きくない（1つあたり、
数十KB程度？）と考えて良いのでしょうか？
> >> 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*」テーブルとそれらのテーブル内にあるカラムです。
以下のもので全てでしょうか？
１．Sources*
２．Lexicon*_0
３．Lexicon*_0._key
４．Lexicon*_0.index
クエリの実行回数をなるべく少なくしたいのですが”_0”や”_key”、”index”
は固定値として処理してしまって大丈夫でしょうか？
あと、データベースに対するコマンド（--recursive no）は各オブジェクト毎に
実行した方が良いのでしょうか？それとも最後に1回実行すれば良いのでしょう
か？
-----------------------------
高見 直輝 <takam****@orega*****>
株式会社オレガ
TEL:03-3267-0150
FAX:03-3267-0180