Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

[fukken]

サンプリング調査か、その発想は無かった

[kotaro-ono]

mysql チューニング手法

[ruicc]

mprofile

[gachakku0131]

SHOW PROCESSLIST コマンドを使った統計的アプローチ、スロークエリの参照など

[girled]

動かしてみた。スロークエリには引っかからないけど累積すると常時負荷かけてるようなクエリを分析できるのはすごいいいなあ。つか、何より軽快すぎ!気兼ねなく監視、調査できるってのは柔軟な対策には不可欠だな。cr

[kulamochi]

クエリ自体の負荷をチェックしクエリを改善するチューニング方法。

[kgbu]

SHOW PROCESS LISTコマンドで、実行中のクエリのサンプルを取得して、その頻度と負荷の積でsortして重点的に撃破するというもの。

[aprl]

mysql

[ysibata]

mysql

[bonnaroo]

querylogをコマンドで統計できるようだ。これはいい。

[HISAMATSU]

これはいい．

[hoisjp]

SHOW PROCESSLISTの結果をためて解析するアプローチ。なるほどー。＞・既存環境の変更が不要　・サンプリングによるので負荷が軽い　・スクリプトを組み合わせて、柔軟なチューニングや監視の仕組みを作ることができる

[daira4000]

ボトルネックを解析

[mumincacao]

mysqldumpslow でのやりかたも見たけどさ～ばの構成変えずにできるのはうれしいにゃぁ．．．〆（・ｘ・。【みかん　確実に重たいってわかってるくえりを最適化するには EXPLAIN も効果的なんだけど・・・

[homajyu]

ボトルネックの監視方法

[homaju]

ボトルネックの監視方法

[comogly]

% mpfilter < mpdump.txt | mpreport | head -100

[mainyaa]

mpdump, mpreport

[crenlif]

"ボトルネックとなっている SQL を解析する手段としては、他にスロークエリログを使う手法 (参考: MySQL 5.1のmysqldumpslowで快速チューニング - SH2の日記) や、MySQL Enterprise Monitor を使うという手もあります。これらと比較して、

[Chisei]

参考になる

[hiro_y]

show processlistの結果をモニタリングしてボトルネックを解析。

[tasukuchan]

love

[seiunsky]

うお、すげええええええ！！！／rotatelogs 初めて知った！＞＜

[mabots]

MySQLのボトルネック解析について複数アプローチをとるべきだがこの記事の内容が有効な選択肢の一つであることに間違いはない。

[nihen]

よさげ

[sotarok]

mprofile http://coderepos.org/share/browser/platform/mysql/mprofile

[IwamotoTakashi]

「あとは、この一覧の順に、最適化が可能か、あるいは memcached でキャッシュすべきか、といったことを検討していくことになります。」

[machataka]

show processlist

[download_takeshi]

パフォーマンスチェック