Naoya Murakami
visio****@gmail*****
2013年 9月 6日 (金) 10:28:36 JST
お世話になっております。村上です。 インデックス構築に失敗していた英語のデータベースのインデックスを３分割に してやったのですが、同様にインデックス構築に失敗しました。 2013-09-06 07:54:16.979802|n|a01de700|grn_ii_buffer_commit: tmpfd: 398 2013-09-06 07:54:16.979812|n|a01de700|grn_ii_buffer_commit: close tmpfd 2013-09-06 07:54:16.979826|n|a01de700|grn_ii_buffer_commit: block_buf: 0x7f8130b9c010 2013-09-06 07:54:16.979834|n|a01de700|grn_ii_buffer_commit: free block_buf 2013-09-06 07:54:16.980199|n|a01de700|grn_ii_buffer_commit: counters: (nil) 2013-09-06 07:54:16.980215|n|a01de700|grn_ii_buffer_commit: free counters 2013-09-06 07:54:16.980295|n|a01de700|grn_ii_buffer_commit: update_buffer_size: 10 2013-09-06 07:54:16.980311|n|a01de700|nblocks=2798, update_buffer_size=49579308242 2013-09-06 07:54:16.980319|n|a01de700|grn_ii_buffer_commit: datavec_init 2013-09-06 07:54:16.980327|n|a01de700|grn_ii_buffer_commit: datavec_init: 0 2013-09-06 07:54:16.980346|n|a01de700|grn_ii_buffer_commit: opened tmpfd: 398 2013-09-06 07:54:16.980354|n|a01de700|grn_ii_buffer_commit: fetch: 2798 2013-09-06 07:54:30.533953|n|a01de700|grn_ii_buffer_commit: hits: 2798 2013-09-06 07:55:20.818899|n|a01de700|nterms=1 chunk=1113725 total=3173740KB 2013-09-06 07:55:32.896738|n|bb90b720|mroonga 3.07 started. 130906 7:55:30 - mysqld got signal 11 ; Thread pointer: 0x3670330 Attempting backtrace. You can use the following information to find out where mysqld died. If you see no messages after this, something went terribly wrong... stack_bottom = 0x7fa4a01dde60 thread_stack 0x40000 /usr/local/mysql-5.5.14-spider-3.0-vp-0.18-hs-1.2-q4m-0.95-linux-x86_64-glibc25/bin/mysqld(my_print_stacktrace+0x33)[0x769623] /usr/local/mysql-5.5.14-spider-3.0-vp-0.18-hs-1.2-q4m-0.95-linux-x86_64-glibc25/bin/mysqld(handle_segfault+0x36e)[0x4f0b3e] /lib64/libpthread.so.0[0x318c00f500] /usr/lib64/libgroonga.so.0[0x3445509ef1] /usr/lib64/libgroonga.so.0[0x3445510d03] /usr/lib64/libgroonga.so.0(grn_p_encv+0x3e1)[0x34455112a1] /usr/lib64/libgroonga.so.0[0x3445529719] /usr/lib64/libgroonga.so.0(grn_ii_buffer_commit+0x600)[0x344552ae30] /usr/lib64/libgroonga.so.0(grn_ii_build+0x4b5)[0x344552b6f5] /usr/lib64/libgroonga.so.0(grn_obj_set_info+0xaec)[0x344545618c] 今回は、46GiB（49579308242）程度で失敗しています。 他のサーバで、これよりもさらにでかいインデックスサイズの日本語のデータベース もあるのですが、そちらは、インデックスを分けることにより、インデックス構築に 成功しました。一番大きいインデックスで58.6GiB(63012233352)でした。 インデックス総サイズも成功しているデータベースの方が大きいです。 なお、こちらも分割前はインデックス構築に失敗していました。 したがって、今回のケースはインデックスのサイズ以外が要因となっていると 思われます。 環境またはデータそのものが悪いおそれがあるのでしょうか。。 日本語のサーバも分割前は失敗していることからインデックスサイズが要因 のものもある？ うーん、困りました。。 分割してもだめとなると、環境が悪いことが要因かどうかを切り分けるために、 成功したサーバの方でインデックス構築を試してみるぐらいですかね （データの整理等が大変ですが、）。。 環境といっても、メモリとスワップの容量は、どちらも同じで、 CPUとディスクサイズぐらいしか違いがありませんので、あまり うまくいく見込みがありません。 以上、よろしくお願いします。
