お題の通り話してきました。
@kamipoさんOracle Ace認定おめでとうございますの会でした。
ハッシュタグ(#mysql_jp)見てると自分の話は誰得だったのか良く分からんなぁと。
こんなツールがあってこんなこと見れるんだよ、というのを知ってもらえたのなら十分かと思います。
dimSTATのインストール方法とかは以前のはてダに書いてあるので興味をもたれた方は参考にしてもらえると幸いです。
スライドの補足
5.7.8でパラメータの挙動の違いについて見てみた、の環境はLinkbenchのスコアから推測出切るとは思いますがxfs使っています。
本当はもうちょっと突き詰めたかったんですが時間が足りませんでした。
またデモの時に流したLinkbenchは
innodb_io_capacity = 55000
innodb_io_capacity_max = 60000
でどうなるか試した内容でした。結果のスコアは34905なのでやはり上げすぎない方が性能は出るようです。
その際にgeneral_log有効にしてもあまり遅くならなかったよ、と
話した部分がありますが、それはあくまでもバッファプールに
データが乗り切らなくなり、データに満遍なくアクセスがある
ケースです(ioが頻繁に発生する状況)。
データ・INDEXがバッファプールに全部載っている状態、または
アクセスされるデータに局所性がある場合はgeneral_logの待ちにより
全く性能がスケールしなくなります。
この辺についてはMySQL calualのSlackチャンネルの過去ログを見て
頂ければと思います。
innodb_monitor, performance_schemaの細かい部分はドキュメントもなく、
意味するところはソースのコメント見ないといけなかったりするのが
まだ残念な状態です。項目名から意味を類推しつつソース覗いてみて、
あとはベンチマーク実行して挙動をみてみる感じになっています。
※ソースをがっつり読める人はもうちょっと楽だと思います。
ext4の方がどうして遅いのかな、とfio + perf + Flame Graphsで載せましたが、
MySQL + perf + Flame Graphsじゃないのはベンチマーク中にperfをMySQLに対して
実行すると8割以上Kernel panicやら何も出力なく固まるやらしたためでした。
運良く取れたのもあるんですが、これが原因、というのが見やすい感じじゃ
なかったので載せてません。
writeonlyだとext4が遅いですが、readの場合はmutex_lock取らないので
readonlyならfioで計測されるiopsはext4もxfsとほぼ同じになります。
readwriteだと当然xfsが優勢です。
会場提供のGMOさん、主催のyoku0825さん、ありがとうございました。
