Kouhei Sutou
kou****@clear*****
2013年 8月 28日 (水) 11:48:08 JST
須藤です。 In <CANM+Hhc5d1KRQhjdxzWRpBRDELrJrZO2Ma8cK5b9ws=vAmd8****@mail*****> "[groonga-dev,01708] Re: 仮想メモリサイズを超えるmroongaのインデックス構築について" on Wed, 28 Aug 2013 08:47:20 +0900, Naoya Murakami <visio****@gmail*****> wrote: > 再現させてみました！ ありがとうございます！ > 予想とは少し違うかもしれませんが何かわかりそうですか？ たしかに、予想と違いますね。。。 grn_ii_buffer_merge()かgrn_ii_buffer_chunk_flush()の中で落ち ていそうなことがわかります。でも、この中からfree()してそうな のはgrn_io_win_unmap2()の中なんですよねぇ。 grn_io_win_unmap2()ならstaticでもないし↓の中にでてきそうな もんなんですが。。。 > /usr/lib64/libgroonga.so.0(grn_free_default+0x31)[0x7f11d61478f1] > /usr/lib64/libgroonga.so.0(+0x10b0d4)[0x7f11d62310d4] > /usr/lib64/libgroonga.so.0(+0x128e27)[0x7f11d624ee27] > /usr/lib64/libgroonga.so.0(grn_ii_buffer_commit+0x600)[0x7f11d6250e10] ということで、さらに絞り込む必要があることがわかりました。。。 すみません。。。gdb経由でmysqldを起動してクラッシュしたらgdb でバックトレースをとってもらえないでしょうか？MySQLが出力し ている↑のバックトレースは、たぶん、glibcのbacktrace()という 関数でとっているんですが、それだと関数名くらいしか情報がとれ ないのです。しかし、gdbでは↑でとれていない関数名もとれる上 に引数の値までとれるのです。 以下、手順です。 まず、mysqldの起動コマンドラインを確認します。 % ps axuwww | grep mysqld たとえば、こんな感じになっていると思います。 /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql --plugin-dir=/usr/lib/mysql/plugin --user=mysql 通常はmysqld_safe経由で起動していると思いますが、mysqld_safe の方ではなくmysqldを使っている方を確認してください。 mysqldの起動コマンドラインがわかったら以下のように最初に 「gdb --args」をつけて、mysqldの起動オプションに「--gdb」を つけてください。 % sudo gdb --args mysqld --gdb ...（確認した起動オプション）... 以下のようにgdbのプロンプトがでるので、「run」と入力してくだ さい。 (gdb) run これでmysqldが動き出すのでデータを投入してください。 クラッシュするとまたgdbのプロンプトがでているので 「thread apply all backtrace full」と入力してください。 (gdb) thread apply all backtrace full 出力が多くてたくさんのページにわけて表示されます。ページごと に↓が出力されるので、Enterを押してまたgdbのプロンプトがでる まで表示してください。 ---Type <return> to continue, or q <return> to quit--- ぜんぶ表示されたらそれをコピペして教えてもらえるとうれしいで す。 > ブランチのソースから、too many postings回避のため、以下を書き換えています。 > ３分割したときは、これを書き換えても、うまくいっていたので、これが原因かは > わかりませんが、ii.cなので、ひょっとしたら、これが悪いのかもしれません。 > そうだったら、ごめんなさい。 > > #define GRN_II_MAX_TF 0x1ffff → #define GRN_II_MAX_TF 0x1fffff オフラインインデックス構築のときはこの値を使っていないので影 響はないと思います。 あれ、とすると、オフラインインデックス構築のときはtoo many postings相当のチェックはしていないのかも。。。そしたらそれが 原因で不整合が発生しているのかも。。。 gdbでのバックトレースをみてみないとなんとも言えませんが、も しかしたら、データのサイズではなく、データの内容が原因の可能 性もあるかなぁと思いました。 > 2013-08-28 05:39:23.951606|n|d4172700|grn_ii_buffer_commit: hits: 5313 > 2013-08-28 05:39:32.901323|n|d4172700|nterms=6 chunk=1230 total=1KB > 2013-08-28 05:39:40.755374|n|d4172700|nterms=1 chunk=1003688391 > total=980165KB > 2013-08-28 05:39:40.768927|n|d4172700|nterms=2 chunk=1018907 total=981160KB > 2013-08-28 05:39:43.871382|n|d4172700|nterms=9 chunk=164 total=981160KB > 2013-08-28 05:39:51.514877|n|d4172700|nterms=12 chunk=899969567 > total=1860037KB > ・・・ > 2013-08-28 05:40:48.445918|n|d4172700|nterms=163 chunk=736791 > total=5903876KB > 2013-08-28 05:40:48.495673|n|d4172700|nterms=384 chunk=726545 > total=5904586KB > 2013-08-28 05:40:48.531348|n|d4172700|nterms=634 chunk=503434 > total=5905077KB > 2013-08-28 05:40:48.560509|n|d4172700|nterms=188 chunk=506237 > total=5905572KB > 2013-08-28 05:40:48.599969|n|d4172700|nterms=298 chunk=959292 > total=5906508KB > 2013-08-28 05:40:48.660974|n|d4172700|nterms=236 chunk=2186602 > total=5908644KB > 2013-08-28 05:40:53.354674|n|5b7af720|mroonga 3.07 started. うーん、最後はnterms=の連続ですかぁ。chunk:XX, packed_len:YY もでそうだなぁと思ったんですが、どう動いているのかしら。。。 あ、chunk:XXはnoticeじゃなくてinfoだから入っていないだけです ね。 > /usr/lib64/libgroonga.so.0(grn_free_default+0x31)[0x7f11d61478f1] > /usr/lib64/libgroonga.so.0(+0x10b0d4)[0x7f11d62310d4] > /usr/lib64/libgroonga.so.0(+0x128e27)[0x7f11d624ee27] > /usr/lib64/libgroonga.so.0(grn_ii_buffer_commit+0x600)[0x7f11d6250e10] > /usr/lib64/libgroonga.so.0(grn_ii_build+0x4b5)[0x7f11d62516d5] デバッグオプションをつければ関数名がでるかと思ったんですが、 static付きのやつはでないんですね。残念。。。 -- 須藤 功平 <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
