Tetsuro IKEDA
ikdtt****@gmail*****
2007年 4月 24日 (火) 19:44:21 JST
こんにちは。池田＠tritonnプロジェクトです。 うたださん、情報ありがとうございます。 よろしければ以下についてもいただけないでしょうか？ - show statusで得ることができる"Handler_XXX" (XXXにはHandler API の名前が入る）の値が、遅いキーワードと速いキーワードでそれぞれ どのようになっているか。 # 投げる前にflush statusを実行して値をクリアして取得してみてください。 - 遅いキーワードの時のvmstat等によるリソースのボトルネック 07/04/24 に Katsuya Utada<utada****@themi*****> さんは書きました: > お世話になっております > うただです > > |2ind機能はまだ未完成の部分がある＆不具合があると認識しております。 > |こうした具体的な情報は非常にありがたいです。 > 2ind利用時のパフォーマンスに関してですが > 当方でもMySQL5.0.37+tritonn-1.0.2.mysql-5.0.37.senna-1.0.4(ngram) > の環境で、特定のキーワードで応答が極端に遅くなる場合があります。 > 2ind ON/OFF時でも応答時間に変化は見られませんでした。。 > 遅延の発生する条件が分かりませんが、 > 一応情報としてレポートさせて頂きます。 > > 安定性が上がったのは大変助かっております。 > 今後の改良に期待致しております。 > |mysql> show senna status\G > |*************************** 1. row *************************** > | Table: sitest > | Key_name: keywords > | Column_name: keywords > | Encoding: euc_jp > | Index_type: NGRAM > | Normalize: ON > | Split_alpha: OFF > | Split_digit: OFF > | Split_symbol: OFF > | Initial_n_segments: 512 > | Senna_keys_size: 4624378 > | Senna_keys_file_size: 113319936 > | Senna_lexicon_size: 2503513 > |Senna_lexicon_file_size: 67182592 > | Senna_inv_seg_size: 181833728 > | Senna_inv_chunk_size: 485888000 > > |mysql> select count(*) from sitest where match(keywords) against('コン'); > |+----------+ > || count(*) | > |+----------+ > || 371907 | > |+----------+ > |1 row in set (0.11 sec) > | > |mysql> select count(*) from sitest where match(keywords) against('パソコン'); > |+----------+ > || count(*) | > |+----------+ > || 278108 | > |+----------+ > |1 row in set (30.95 sec) > > > > On Wed, 28 Mar 2007 20:05:47 +0900, Tetsuro IKEDA wrote: > |こんにちは。池田＠Tritonnプロジェクトです。 > | > |2ind機能はまだ未完成の部分がある＆不具合があると認識しております。 > |こうした具体的な情報は非常にありがたいです。 > | > |またTritonnでのMySQL 4.1対応ですが、他にもいろいろなTODOがあり、 > |何を優先して行うかは議論のあるところなのですが、 > |こうした要望をいただけますと、非常に参考になります。 > |ありがとうございます。 > | > |07/03/28 に 坂根 有<sakan****@skygr*****> さんは書きました: > |> お世話になります。坂根と申します。 > |> > |> 先日、末長様へ個人的にメールさせて頂きましたが > |> MLのほうで報告をすればサポートできるかもというこでしたので > |> 期待を込めてメールさせていただきます。 > |> > |> 何点か不具合と思われる現象がありました。 > |> > |> 動作確認環境は以下の通りです。 > |> > |> 環境１ > |> mysql-5.0.37 + tritonn-1.0.0.mysql-5.0.37.senna-1.0.2 > |> Senna 1.02 > |> MeCab > |> > |> 環境２ > |> mysql-4.1.22 + 4.122用MySQLバインディングパッチ（末長様に頂きました） > |> Senna 1.03 > |> MeCab > |> > |> 使用テーブル > |> > |> CREATE TABLE `blog_items` ( > |> `blogid` int(11) NOT NULL default '0', > |> `itemid` int(11) NOT NULL default '0', > |> `commentid` int(11) NOT NULL default '0', > |> `title` varchar(160) NOT NULL default '', > |> `body` text NOT NULL, > |> `more` text NOT NULL, > |> `blog` int(11) NOT NULL default '0', > |> `author` varchar(60) NOT NULL default '', > |> `wdate` date NOT NULL default '0000-00-00', > |> `wtime` datetime NOT NULL default '0000-00-00 00:00:00', > |> `closed` tinyint(2) NOT NULL default '0', > |> `draft` tinyint(2) NOT NULL default '0', > |> `catid` int(11) NOT NULL default '0', > |> `search` text NOT NULL, > |> PRIMARY KEY (`blogid`,`itemid`,`commentid`), > |> KEY `date_idx` (`wdate`), > |> KEY `wtime_idx` (`wtime`), > |> FULLTEXT KEY `author_full_idx` (`author`), > |> FULLTEXT KEY `search_full_idx` (`search`) > |> ) ENGINE=MyISAM DEFAULT CHARSET=ujis; > |> > |> 一回FULLTEXT INDEXは消して > |> ALTER TABLE blog_items ADD FULLTEXT author_full_idx USING NGRAM (author), ADD FULLTEXT search_full_idx (search); > |> で作り直しました。 > |> > |> CREATE TABLE `master_blog` ( > |> `blog_id` int(11) NOT NULL auto_increment, > |> `blog_name` varchar(100) NOT NULL default '', > |> `blog_dir` varchar(20) NOT NULL default '', > |> `blog_dbname` varchar(20) NOT NULL default '', > |> `blog_url` varchar(100) NOT NULL default '', > |> `search_flag` tinyint(4) NOT NULL default '0', > |> `sum_flag` int(11) NOT NULL default '1', > |> `access_group` text NOT NULL, > |> `partner_flg` tinyint(4) NOT NULL default '0', > |> `daredemo_flg` tinyint(4) NOT NULL default '0', > |> `status` varchar(20) NOT NULL default '', > |> PRIMARY KEY (`blog_id`) > |> ) ENGINE=MyISAM DEFAULT CHARSET=ujis PACK_KEYS=0 AUTO_INCREMENT=231 > |> ; > |> > |> データはblog_itemsには35万レコード,master_blogには231レコードは行っております。 > |> > |> まず以下の比較的簡単なクエリで4.1環境では0.2秒で終わるクエリが > |> 5.0環境では20秒近くかかり極端にパフォーマンスが落ちました。 > |> > |> 実行した SQL: > |> SELECT SQL_CALC_FOUND_ROWS * > |> FROM blog_items > |> LEFT JOIN master_blog ON blog_items.blogid = master_blog.blog_id > |> WHERE blog_items.blogid = 5 LIMIT 0 , 100 > |> > |> 4.1環境でのEXPLAIN結果 > |> id select_type table type possible_keys key key_len ref rows > |> Extra > |> 1 SIMPLE blog_items ref PRIMARY PRIMARY 4 const 28378 Using where > |> 1 SIMPLE master_blog eq_ref PRIMARY PRIMARY 4 bcounter.blog_items.blogid 1 > |> > |> 5.0環境でのEXPLAIN結果 > |> id select_type table type possible_keys key key_len ref rows Extra > |> 1 SIMPLE blog_items ref PRIMARY PRIMARY 4 const 36801 > |> 1 SIMPLE master_blog const PRIMARY PRIMARY 4 const 1 > |> > |> パッチを当てていないMYSQL5.0でも検証しても > |> 起こるためMYSQL5.0の問題と思っております。 > |> > |> そこで5.0ではパフォーマンスがでないため > |> 末長様にMYSQL4.1.22用のパッチを頂きました。 > |> > |> MYSQL4.1では全体的にパフォーマンスもよく検索できておりましたが > |> バグと思われる挙動があり困っております。(MYSQL5.0+Tritonn環境でも発生します） > |> > |> ------------------------------------------------------------------------------------------ > |> 1点目 0件目からのLimitでない場合結果が取得できない。 > |> ------------------------------------------------------------------------------------------ > |> 以下のクエリは正常に結果が取得できます。 > |> SELECT * FROM blog_items > |> LEFT JOIN master_blog ON blog_items.blogid = master_blog.blog_id > |> WHERE MATCH (search) AGAINST ('test') AND master_blog.search_flag =1 > |> LIMIT 0,10 > |> > |> ところが以下のようにLIMITで0件目からの取得でない場合結果が空になります。（カウントでは200件あります） > |> SELECT * FROM blog_items > |> LEFT JOIN master_blog ON blog_items.blogid = master_blog.blog_id > |> WHERE MATCH (search) AGAINST ('test') AND master_blog.search_flag =1 > |> LIMIT 10,10 > |> ------------------------------------------------------------------------------------------ > |> > |> ------------------------------------------------------------------------------------------ > |> 2点目 SQL_CALC_FOUND_ROWSで総件数を取得する場合limitの値で総件数が変動します。 > |> ------------------------------------------------------------------------------------------ > |> SELECT SQL_CALC_FOUND_ROWS * FROM blog_items WHERE MATCH (search) > |> AGAINST ('test') AND (master_blog.search_flag = 1) limit 120,10 > |> > |> と > |> > |> SELECT SQL_CALC_FOUND_ROWS * FROM blog_items WHERE MATCH (search) > |> AGAINST ('test') AND (master_blog.search_flag = 1) limit 10,10 > |> > |> では違う件数になってしまいます。 > |> ------------------------------------------------------------------------------------------ > |> > |> 2indパッチを当てずに検証しましたところ発生いたしませんでした。 > |> > |> 現状2indパッチを使用しない形で実運用に組み込もうと考えておりますが > |> 今後のことが少々不安ですのでTritonnプロジェクトでの > |> 4.1系の開発を要望としてあげさせていただきます。 > |> > |> 以上よろしくお願いいたします。 > |> > |> _______________________________________________ > |> Senna-dev mailing list > |> Senna****@lists***** > |> http://lists.sourceforge.jp/mailman/listinfo/senna-dev > |> > | > |_______________________________________________ > |Senna-dev mailing list > |Senna****@lists***** > |http://lists.sourceforge.jp/mailman/listinfo/senna-dev > | > | > > --- > Katsuya Utada <utada****@themi*****> > > _______________________________________________ > Senna-dev mailing list > Senna****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/senna-dev >
