HAYASHI Kentaro
hayas****@clear*****
2015年 4月 7日 (火) 18:47:31 JST
林です。 On Mon, 6 Apr 2015 11:54:42 +0900 Masato Shimada <cymba****@gmail*****> wrote: > お世話になっております、嶋田です。 > > > select ID from TABLE where DATETIME > 1400031915 order by DATETIME > > > (desc|asc) limit 100 > > > →0.45 sec（Mroonga） > > > > > > select ID from TABLE where DATETIME > 1270031915 order by DATETIME > > > (desc|asc) limit 100 > > > →5.48 sec（Mroonga） > > これは両方共、ストレージモードで試したらこの結果だったという例ですよね。 > > show profileでどこに時間がかかっていそうかってわかりますか？ > > 参考: Mroonga 3.11に追加されるDATETIME型のORDER BY最適化 > > > > http://tech.gmo-media.jp/post/69542751128/mroonga-311-new-optimization > > ↑は全文検索を含んでいるなどクエリの内容が違うやつなんですが、 > > show profileの例としてあげてみました。 > > show profileの結果ですが、 statisticsとpreparingが半々くらいの割合でほぼDuration全体を占めています。 > 全文検索を含めた場合はstatisticsとFULLTEXT initializationが半々くらいの割合でほぼDuration全体を占めています。 > 範囲の広さに応じて応答時間が増減しますが、statusのDurationの割合は一定です。 うーん、statisticsとかが結構な割合を占めるというのは変な気もしますねぇ。 FULLTEXT initializationはMroongaが全文検索を頑張っている状態だったはずなので、 それが半分を占めていて重い、というならどっかしらボトルネックがないか 順にみていくとよさそうです。 1. インデックスをうまく使えていない これはなさそうな気がしたのですっとばして2.に進んだのですが、 念のためexplainで期待通りにindex使えているかは確認したほうがいいかも知れません。 2. show profileでどこに問題ありそうかみてみる(これは前回のメールで確認してもらったやつですね) 参考: https://dev.mysql.com/doc/refman/5.6/en/general-thread-states.html 3. CPUを使い切れていない or ディスクIOがボトルネックになっている vmstatのcpuとかswapあたりをみてみると何かわかるかも知れません。 参考: http://www.fulldigit.net/content/view/54/6/ CPU使用率が低くて頑張れていないのか、あるいはswapのsi,soが高めになっていないか、など。 -- HAYASHI Kentaro <hayas****@clear*****>
