Kouhei Sutou
kou****@clear*****
2017年 1月 30日 (月) 12:57:35 JST
須藤です。 In <50DF0****@gmail*****> "[groonga-dev,04266] Re: Mroongaストレージモードでmysqld got signal 11" on Fri, 27 Jan 2017 12:10:01 +0900, murata satoshi <murat****@gmail*****> wrote: > 早速発生しました。 そうですか。。。 > stack trace及びcore dumpを見たところ、前回報告時と同じSQL(mroonga_command)で同じ箇所でした。 > #3 0x00007f96f9308b8a in grn_ii_cursor_next_internal (ctx=0x7f9588288540, c=0x7f95ac370e90, options=<optimized out>) at ii.c:5102 > 5102 c->pc.rest = c->pc.tf = 1 + *c->ctp++; > > groonga.logには下記が出力されていましたが、クラッシュした時間とかなり離れています。 > 2017-01-27 07:31:06.814808|w|aa4a6700|[ii][cursor][chunk] chunk(36832) is reused by another thread: 0x7f94801e4cc0 > 2017-01-27 07:59:39.974877|w|3b37f700|[ii][cursor][chunk] chunk(38384) is reused by another thread: 0x7f95343191f0 > *クラッシュした時間は10:21。 groonga.logも見せてもらうことはできますか？ また、念のため、GRN_II_CURSOR_SET_MIN_ENABLE=noが本当に効い ているかも確認した方がよさそうと思っています。 SET mroonga_log_level = 'debug'; をした状態のgroonga.logを確認すると効いているかがわかります。 効いているなら [ii][cursor][min] skip ... みたいなのがでるんですが、効いていないならでません。 > yokuさんのようにcoreからthread apply all bt fullと、frame3でのp*cを置きました。 > (bt fullの方、セキュリティ上テーブル/カラム名等を書き換えています。） > https://gist.github.com/muratapo/ef857c6f920da088048af768f71f78aa/raw/f5cb391370a3e4c9dab0f0db2389ecfcbb312f4a/thread_apply_all_bt_full.txt > https://gist.github.com/muratapo/ef857c6f920da088048af768f71f78aa/raw/f5cb391370a3e4c9dab0f0db2389ecfcbb312f4a/thread1_frame3_p_c.txt ありがとうございます！ こっちもトークンIDが1のチャンクで落ちているんですね。 うーん。 -- 須藤 功平 <kou****@clear*****> 株式会社クリアコード <http://www.clear-code.com/> Groongaベースの全文検索システムを総合サポート： http://groonga.org/ja/support/ パッチ採用 - プログラミングが楽しい人向けの採用プロセス： http://www.clear-code.com/recruitment/ OSS開発支援サービス: http://www.clear-code.com/blog/2016/6/27.html
