Naoya Murakami
visio****@gmail*****
2014年 9月 20日 (土) 11:36:44 JST
村上と申します。 ・公式サイト（http://groonga.org/ja/blog/2014/08/29/release.html）の > ・1つの文書に同じトークンが大量に含まれている場合、インデックス構築時 > に無限ループが発生 する問題を修正しました。 に関して、同じトークンが大量に含まれているというのは具体的にどの程度の量 なのかという点 単純に同じトークンが大量に含まれているという条件ではないようです。 同じトークンが大量に含まれており、且つ、b->header.ntermsがかなり大きい ときのようです。 トークン数の方は、少なくとも同一トークンが13万個以上は必要だと思います。 b->header.ntermsはトークンの種類かと思ったのですが、ここは単純には 増えずよくわかりませんでした（キーの種類も関係しているかもしれません）。 かなりこみいった条件のようで、私の方で再現データを作るのは困難でした。 ただ、以下の検討内容のように、同一トークン数が非常に多いのは必須ぽい のでログを見れば、too_many_postingsの警告がでていそうです。 （ぎりぎりでない範囲があるかもしれませんが。） ＜ご提案＞ 横山さんの言うとおり、作業内容の提示とともにログを確認することをお勧め します。ログを見れば、本件と関係があるか、ある程度の推察ができるかも しれません。 本件以外が原因でも、ログから原因がわかる可能性もあります。 たとえば、更新中に強制終了等すれば、ロックが残留していたりするケースも あります。この場合、ロックしているぽいメッセージがログにでていると思い ます。 ちなみに、groonga --log-path groonga.log --log-level 8でデバッグレベルの ログファイルが出力できます。 ＜検討内容＞ 以下、検討内容です。 ちょっとまとまっておらず、わけがわからないと思います。 本件に関するコミットは以下です。 https://github.com/groonga/groonga/commit/9f9c4b82ec37eafd37230956a502a958da65e261 このコミットを参照すると、 buffer_newに、 (1)S_SEGMENT - sizeof(buffer_header) < size + sizeof(buffer_term) の場合のリクエストサイズ過多のエラー処理と、 (2)S_SEGMENT - sizeof(buffer_header) - b->header.nterms * sizeof(buffer_term) < size + sizeof(buffer_term) の場合のbreak処理が追加されています。 S_SEGMENTは、2の18乗で262144バイト(256Kバイト)です。 sizeof(buffer_header)、sizeof(buffer_term)は128バイトです。 sizeの部分は、同一トークンの出現数が増えると増えていきますが、あまり 多すぎるものは、posting数超過の警告で捨てられて最大で131072で止まります。 同一トークンがものすごく多いだけでは、(1)、(2)の判定には影響がなさそうです。 b->header.ntermsは最初トークンの種類だと思ったのですが、トークンの種類だけ では、単純には増えませんでした。 ソースをあまり深く追ってないので、b->header.ntermsを規則的に伸ばす方法は わかりませんでした。 (私の現在のC読解力では、バッファー処理の部分を追うのは相当厳しい。。) このb->header.ntermsが1024を超えるか、あまりにchunkサイズ大きいとバッファーが 分割されてしまうようです。なので、b->header.ntermsの最大値は1024です。 b->header.ntermsを1024とすると、(2)の条件は size > 130816となります。 https://github.com/groonga/groonga/blob/9f9c4b82ec37eafd37230956a502a958da65e261/lib/ii.c#L3394 https://github.com/groonga/groonga/blob/9f9c4b82ec37eafd37230956a502a958da65e261/lib/ii.c#L3349-L3351 さらに、(2)の条件に至るには、b->header.buffer_free以下である必要もあります。 https://github.com/groonga/groonga/blob/9f9c4b82ec37eafd37230956a502a958da65e261/lib/ii.c#L3389 以上です。 2014年9月19日 22:15 Masafumi Yokoyama <myoko****@gmail*****>: > 横山です。 > > 私もWindowsを使っているので協力させてください。 > > 2014年9月19日 16:47 野本 航平 <knomo****@reedr*****>: > >> 皆川さんの報告だと無限ループになるのでCPU使用率は100%になり > >> そうに思いました。でも、野本さんのケースは0%なんですよねぇ。 > > 確かに無限ループでCPU使用率が0%というのはなにか違うような気もします。 > > 他にgroonga稼働中に応答がかえって来なくなるような不具合の情報が出て > > いなかったため、こちらの問題ではないかと思い前回のようなご質問をさせ > > ていただきました。 > > まず状況を整理したいので、差し支えない範囲で、loadコマンドの実行手順と > 応答がかえって来ない状態についてもう少し詳しく教えていただきたいです。 > > たとえば、以下のような感じでしょうか？違うところがあればご指摘ください。 > > 1. groongaコマンドで対話モードに入る > 2. loadコマンドでデータをロード > 3. loadコマンドが終了しない（対話モードのプロンプトが戻って来ない） > 4. タスクマネージャーのgroonga.exeはCPU0%で残ったまま > > http://packages.groonga.org/windows/groonga/groonga-4.0.1-x86.exeで試したところ、 > 対話モードに入った時点でタスクマネージャーにgroonga.exeのプロセスが表示されていて、 > CPUは0%です。なので、もし上記の手順であれば、loadコマンドは終了しているけど > プロンプトが戻って来ていない状態と考えられます。 > > もし可能であれば、データは空にした状態で結構ですので、問題が起こったときに > 実行されたコマンドを全て教えていただけると助かります。 > > お手数ですが、よろしくお願いします。 > > -- > 横山 昌史 (Masafumi Yokoyama) > _______________________________________________ > groonga-dev mailing list > groon****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/groonga-dev >
