MySQLのクエリ集計手法いろいろ
Webサービスを開発/運用してるモンとしては、いろんなWebサービスを触ってみなきゃアカンってことで、アメリカの若モンに大人気ってふれこみのsnapchatに登録してみた。これでリア充の仲間入りやと思ったが、snapchat友達が同僚二人しかいないうえに、利用シーンがあまり思い浮かばないww オジサン困っちゃいました。画像とか送信できるんだけど、数秒で消えるの。むしろそこがウリっていうね。どうやって遊ぼうか…。
2月はブログ書かなかったなーと思ったのでMySQL小ネタ。世間的にも自分的にも真新しくもなんともないTipsです。
innotopで集計
実は以前、Qiitaに書いたので↓をば。。。
http://qiita.com/la_luna_azul/items/505ca441b8c8e6a87aaa
流れるクエリ、ロックの状況、トランザクション(show engine innodb statusのサマリ)、などその他諸々を見ることができる。本番環境で流れているクエリを見たいときにshow processlistを鬼連打したりinformation_schemaをシコシコ調べたりするよりは断然楽。重宝します。
実行の際にサンプリングのインターバルを指定できる(0.0001秒とか)んだけど、サンプリングから漏れる場合もある。
pt-query-digest&tcpdumpで集計
percona-toolkitに入ってる。
http://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html
使い方は上記公式ドキュメントの通り。一旦tcpudmpを抜く必要があるのでストレージ容量などに注意。数時間取りっぱなしとかすると結構なサイズになると思う。innotopは漏れもあると書いたけど、こちらの手法はtcpdumpで全抜きするので漏れはない。以下の使い方の例は、テーブルごとに集計するときのコマンドなんだけど、select文だけを抽出したり、更新系クエリだけを抽出したり、柔軟なサンプリングが可能。公式ドキュメントに詳しく書いてある。
1 2 3 4 | # まずはtcpdumpを取る tcpdump -s 65535 -x -nn -q -tttt -i bond0 -c 10000 port 3306 > ~/work/tcpdump.txt # テーブルごとに集計して出力 pt-query-digest --type=tcpdump --group-by=tables --order-by=Query_time:cnt --limit=100 ~/work/tcpdump.txt > ~/work/result.txt |
結果は次の通り。Item欄にコール数順でソートされてテーブル名が表示される。
サンプリングしたクエリのプロファイルは、上記テーブル一覧の下に次のように表示される。このテーブル(白抜きにして名前を隠してあるが)へのクエリは100us程度でレスポンスを返していることがわかる。
mysqldumpslowでスロークエリを集計MySQLにもとから入っているコマンド。使い方の例は↓。言うまでもないけど、スロークエリログに出力されたもののみが集計対象になる。
1 2 3 4 5 | # 時間かかった順で集計 mysqldumpslow -s t mysql-slow.log # スローログに検出された件数が多い順で集計 mysqldumpslow -s c mysql-slow.log |
結果は次の通り。最も多く検出されたスロークエリは、1406回スロークエリとして検出されて、平均0.97秒(検出された分の合計が1364秒)、処理時間がかかっていることがわかる。
スロークエリに閾値を極端に小さくしておいて、負荷試験→mysqldumpslowで集計→クエリチューニング→負荷試験…などとすると捗る。
バイナリログから集計mysqlbinlogコマンドとLinuxコマンドで泥臭く集計。ソシャゲの運用とかしていると「一ヶ月前のイベントのときどうだったかな〜」などと思うときがあったりする。これはログさえ残っていれば調べることができるので、更新系クエリ限定ではあるがたまにやる。
1 2 3 4 5 | # まずバイナリログをテキストに戻す mysqlbinlog mysql-bin.002547 > mysql-bin.002547.txt # update文の件数をテーブルごとに抽出 cat mysql-bin.002547.txt | grep update | awk '{print $1 " " $2}' | sort -n | uniq -c | sort |
結果はこんな感じ。
NewRelicなどの外部ツールにおまかせ
これが楽で良いんだよね。ビューの一部だけど↓みたいな感じ。もっとも処理時間がかかっている順にテーブルとクエリを教えてくれたりする。便利すぎて俺いらないんじゃないかってレベル。金払う価値あり。強いて言うなら、アクセス頻度の多いテーブルやレスポンスに時間がかかっているテーブルの上位20件くらいまでしか出ない(これでも十分なんだけど)。なので、更新系クエリなどの状況を知りたいときは上に挙げたような手法で調べる必要も出てくる。多くのWebサービスは往々にして参照系が大半を占めると思うし。
おわり
Information
2013/1/24 SPDY 対応しました。不具合あったら教えていただけると喜びます。Top Posts
- - 開発支援系のサービスが充実しすぎて転職か廃業を考えた [30,624 views]
- - about [9,475 views]
- - vm.swappiness=0は重要 [7,490 views]
- - Cassandraメモその1(インストール、データモデル、データ操作について) [5,210 views]
- - Mac OSX+iterm2+tmux+zsh [5,072 views]
- - MySQL バイナリログを使ったデータリカバリ [4,916 views]
- - MySQL ibdata1が肥大化する理由(記事の意訳) [4,417 views]
- - serverspec インフラ層のテスト項目を考える [4,328 views]
- - knifeクライアントの設定とchefの実行 [4,281 views]
- - LVSでDSR(簡易構成) [4,155 views]
Archives
- 2014年3月 (1)
- 2014年1月 (1)
- 2013年12月 (3)
- 2013年11月 (2)
- 2013年10月 (3)
- 2013年8月 (1)
- 2013年7月 (2)
- 2013年6月 (1)
- 2013年5月 (3)
- 2013年4月 (3)
- 2013年3月 (4)
- 2013年2月 (2)
- 2013年1月 (2)
- 2012年12月 (3)
- 2012年11月 (1)
- 2012年10月 (4)
- 2012年9月 (1)
- 2012年7月 (3)
- 2012年6月 (2)
- 2012年5月 (1)
- 2012年4月 (2)
- 2012年3月 (1)
- 2012年2月 (1)
- 2012年1月 (1)
- 2011年11月 (4)