Katsuya Utada
utada****@themi*****
2007年 2月 3日 (土) 02:47:35 JST
うただです On Thu, 18 Jan 2007 02:52:29 +0900 Tasuku SUENAGA wrote: |0.9系の新規インデックスで、追加のみを行っているのであれば |新しいインデックス作成部分に未知のバグが存在する可能性があります。 MySQL-5.0.24a+Senna-0.9.0(ngram) で大きなテーブルをテストしているのですが、当方でもselect時に 語彙によってmysqlがリスタートを起こしたり、応答が遅くなる現象に 当たってしまいます。 300万レコード程のinsert後、fulltext selectをしています。(updateはなし) 落ちるときのmysql.logのログ mysqld got signal 11; This could be because you hit a bug. It is also possible that this binary or one of the libraries it was linked against is corrupt, improperly built, or misconfigured. This error can also be caused by malfunctioning hardware. We will try our best to scrape up some info that will hopefully help diagnose the problem, but since we have already crashed, something is definitely wrong and this may fail. key_buffer_size=1073741824 read_buffer_size=131072 max_used_connections=1 max_connections=150 threads_connected=1 It is possible that mysqld could use up to key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 1374974 K bytes of memory Hope that's ok; if not, decrease some variables in the equation. thd=0xa02a2a0 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... Cannot determine thread, fp=0x77f241ac, backtrace may not be correct. Stack range sanity check OK, backtrace follows: 0x815d174 0x843888 0xa 0x43cae7 0x82afe0c 0x82abaf7 0x822131e 0x8100418 0x81a19a1 0x81c1c0f 0x81c6acc 0x81c7224 0x8174c31 0x817f1ad 0x817fed1 0x81817b2 0x83d371 0x7969be New value of fp=(nil) failed sanity check, terminating stack trace! Please read http://dev.mysql.com/doc/mysql/en/Using_stack_trace.html and follow instructions on how to resolve the stack trace. Resolved stack trace is much more helpful in diagnosing the problem, so please do resolve it Trying to get some variables. Some pointers may be invalid and cause the dump to abort... thd->query at 0xa04d790 = select id from sntest where match(subject) against('譲渡') thd->thread_id=3 The manual page at http://www.mysql.com/doc/en/Crashing.html contains information that should help you find out what is causing the crash. senna.log 02/03:02:25:56.929808|n| RLIMIT_STACK is 4194304 (0) 02/03:02:25:57.249494|n| closing index_file_name ./mysql/time_zone_transition.MYI 02/03:02:25:57.249571|n| closing index_file_name ./mysql/time_zone_transition_type.MYI 02/03:02:25:57.249592|n| closing index_file_name ./mysql/time_zone.MYI 02/03:02:25:57.249613|n| closing index_file_name ./mysql/time_zone_name.MYI 02/03:02:25:57.249634|n| closing index_file_name ./mysql/time_zone_leap_second.MYI 02/03:02:25:57.250390|n| closing index_file_name ./mysql/func.MYI インデックスファイルのサイズ -rw-rw---- 1 mysql mysql 73M 2月 2 20:52 sntest.001.SEN -rw-rw---- 1 mysql mysql 129M 2月 1 18:20 sntest.001.SEN.i -rw-rw---- 1 mysql mysql 795M 2月 2 21:59 sntest.001.SEN.i.c -rw-rw---- 1 mysql mysql 8.1M 2月 1 18:20 sntest.001.SEN.l -rw-rw---- 1 mysql mysql 73M 2月 2 20:51 sntest.002.SEN -rw-rw---- 1 mysql mysql 141M 2月 1 23:17 sntest.002.SEN.i -rw-rw---- 1 mysql mysql 1.0G 2月 1 22:35 sntest.002.SEN.i.c -rw-rw---- 1 mysql mysql 1.0G 2月 2 06:19 sntest.002.SEN.i.c.001 -rw-rw---- 1 mysql mysql 1.0G 2月 2 15:32 sntest.002.SEN.i.c.002 -rw-rw---- 1 mysql mysql 991M 2月 2 21:05 sntest.002.SEN.i.c.003 -rw-rw---- 1 mysql mysql 13M 2月 1 18:22 sntest.002.SEN.l -rw-rw---- 1 mysql mysql 3.8G 2月 3 02:17 sntest.MYD -rw-rw---- 1 mysql mysql 29M 2月 3 02:17 sntest.MYI -rw-rw---- 1 mysql mysql 8.5K 2月 1 18:16 sntest.frm mysql> show create table sntest\G *************************** 1. row *************************** Table: sntest Create Table: CREATE TABLE `sntest` ( `id` int(10) unsigned NOT NULL auto_increment, `filename` varchar(255) default NULL, `date` date default NULL, `subject` varchar(255) default NULL, `body` text, PRIMARY KEY (`id`), FULLTEXT KEY `subject` (`subject`), FULLTEXT KEY `body` (`body`) ) ENGINE=MyISAM AUTO_INCREMENT=2903969 DEFAULT CHARSET=ujis 1 row in set (0.00 sec) GB単位の文章を1テーブルは厳しいでしょうか。 もしご参考になりましたら幸いです。 | |検索結果がざっくりなくなる瞬間を捉えることができれば、 |その前後をログをお見せいただけると問題の切り分けに役立ちます。 |（追加->検索->追加->検索と繰り返して、 | 検索結果件数が広義の単調増加でなくなった場合、 | などのタイミングが適切と思います） | |> ＃個人的には、0.8系インデックスは、1.0でサポートされないのであれば |> ＃切り捨ててもらっても良いと思いますが… |切り捨てる方向性ではあるのですが、 |既存のインデックスを用いた環境でも0.9を気軽に試すことができるように |現在は0.8系のインデックスの読み書き機能を残してあります。 | |>> 更新や削除によってインデックスの一部が破損されるバグがあります。 |>> このバグも0.9.1で修正されます。 |> こちらを試してみたいところですが、環境を0.8.2に戻してしまいました。 |いくつか積み残しがあって、0.9.1はまだリリースできていません。 |0.9.1リリースの際にまたお試しいただけると幸いです。 | |> また、マシン環境と時間があれば0.9系を試してみたいと思います。 |詳細なバグ情報があると大変うれしいです。 | |--- |Tasuku SUENAGA <a****@razil*****> |_______________________________________________ |Senna-dev mailing list |Senna****@lists***** |http://lists.sourceforge.jp/mailman/listinfo/senna-dev | -- Katsuya Utada <utada****@themi*****>
