須藤です。 In <CALHF5KDrSGd0mE+CXd6t2di=JrM98****@mail*****> "[groonga-dev,04948] Re: pgroonga インデックス作成時の [ii][update][one] buffer is full エラー" on Tue, 5 Apr 2022 16:51:46 +0900, takashi sugaya <tsuga****@gmail*****> wrote: > ちなみになのですが、ご指摘いただい箇所を修正したことで、 > なぜ事象が改善したのか、原因をご教授いただくことは可能でしょうか？ 分割処理をするかどうかのしきい値が下がり、今回のデータでも分 割処理が動いて空き領域ができたからです。 buffer is fullがでる直前のログ↓にnterms=782とあります。 2022-04-05 11:27:08.162550|d|6207: flushed a[0]=4915204 seg=75(0x7fc5aebba000) free=32432->249616 nterms=782 v=0 既存のSPLIT_COND()はnterms > 1024なのでnterms（用語数）が 1025以上でないと分割処理が動きませんが、今回のデータは782で す。しきい値を512にすることで今回のデータでも分割処理が動き 空き領域ができました。 ↑のログにもあるとおり分割処理が動かなくても空き領域（free） は32432から249616に増えていますが、今回のケースでは↓のとお り250076必要としていたので足りませんでした。 2022-04-05 11:27:08.162603|A|6207: [ii][update][one] buffer is full: <Lexicon339946_0.index>: <"m">(153): (221588:1): segment:<4915204>, new-segment:<4915204>, free:<249616>, required:<250076> 分割処理が動くことでより空き領域が増えて今回のデータでも処理 できるようになりました。 SPLIT_COND()の条件あるいはbuffer_flush()したあとでもまだ領域 が足りないときの処理を改良することでより汎用的に対応できると は思うのですが、実際に再現するデータが手元にないとどのような 改良処理が適切か試行錯誤できないので、現状では改良するのは躊 躇しています。 > また、私の方で検証しているpgroongaの索引のサイズが約31GB程度あるのですが、 > 索引のサイズなども何か関係する要素がありますでしょうか？ サイズというよりはインデックス対象のデータの傾向（1つのレコー ドに同じ単語が大量に出現するとか）の方が関係します。
