Kouhei Sutou
kou****@clear*****
2013年 8月 29日 (木) 10:32:39 JST
須藤です。 In <CANM+****@mail*****> "[groonga-dev,01714] Re: 仮想メモリサイズを超えるmroongaのインデックス構築について" on Thu, 29 Aug 2013 07:53:21 +0900, Naoya Murakami <visio****@gmail*****> wrote: > gdbのバックトレースを取得しました。以下のような出力がされました。 > 解析できそうでしょうか？ ありがとうございます！ この落ち方のやつは↓で直ると思います。 https://github.com/groonga/groonga/commit/0016ce04ca5c6cd0b7caf8b8c74fa2dbf94916f8 これでパッチを当てられるはずです。 % git fetch --all % git cherry-pick 0016ce04ca5c6cd0b7caf8b8c74fa2dbf94916f8 ただ、これで直るとしたら↑の変更点の直後のGRN_MALLOC()でメモ リーを確保できなくてエラーになっているということです。という ことは、ここのオフラインインデックス構築処理のアルゴリズムを 見なおして、省メモリで動くようにしないと根本的な解決にならな いですね。。。 ただ、それはすぐには無理なので、もっと多くのスワップを用意す るかデータの入れ方を変えるかしないといけなそうです。 もっと多くのスワップがどのくらいかはわからないのですが、倍と かそんな感じになるんじゃないかと思います。というのも、ちまち まメモリを確保してあるところもあれば、数倍分まとめて確保して 使っているところもある（こっちの方が速度が速くなる）からです。 ということで、スワップを多くするのも手探りで微妙なところで す。。。 すみません。。。 > クラッシュしているのとは関係ないのかもしれませんが、デバッグレベルでこんなのが > でていたのが少し気になったり。。 > 2013-08-28 23:28:06.763922|d|f41b0700|[normalizer][mysql-general-ci] failed > to normalize at 3874 byte: ...<0x00 0x00 0x00 0x00 0x00 0x00 0x21 0x2b 0x00 > 0x00 0x00 0x00>... あぁ、U+0000（NULL）は正規化できない文字だからですね。バイナ リデータが入るのであればcollate utf8_binなどとするのがよいと 思います。 > #1 0x00007ffff6b868f1 in grn_free_default (ctx=0x7ffe74820f60, > ptr=0x7fa505fc9010, file=0x7ffff6d44530 "ii.c", > ---Type <return> to continue, or q <return> to quit--- > line=1482, func=<value optimized out>) at ctx.c:2603 > __FUNCTION__ = "grn_free_default" > #2 0x00007ffff6c700d4 in datavec_reset (ctx=0x7ffe74820f60, > dv=0x7ffdf84010b8, dvlen=4, unitsize=18884272, > totalsize=<value optimized out>) at ii.c:1482 > i = <value optimized out> > __FUNCTION__ = "datavec_reset" うーん、<value optimized out>がでていますねぇ。最適化ONでビ ルドされているみたいですねぇ。 あぁ！--with-debugではなくて、--enable-debugでした。。。 すみません。。。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> (03-6231-7270) groongaサポート: http://groonga.org/ja/support/ パッチ採用はじめました: http://www.clear-code.com/recruitment/ コミットへのコメントサービスはじめました: http://www.clear-code.com/services/commit-comment.html
