Post on 07-Aug-2015
これだけみれば大丈夫Cacti によるMySQLパフォーマンス監視のツボ
日本MySQLユーザー会波多野 信広 (札幌MySQL勉強会)
2015/06/13
r2
自己紹介
● 波多野 信広 (twitter @nobuHatano)● 日本MySQLユーザー会 (札幌MySQL勉強会)● 1969年生まれ● 好きなもの SF、ゲーム、美術鑑賞● 超並列サーバーのハード/ソフトサポートを十数年● 札幌のIT企業のインフラとしてMySQL歴三年
札幌MySQL勉強会
● MySQLに関することなら幅広く● たまにしか集まってませんが、ちゃんと勉強してます!
この話の目的
● MySQL超メジャーなのに、モニタリングのグラフの意味や内容を調べようとググっても見つからない
● しかたなく自分で実戦の中で調べて来てわかったことが● せっかくなので経験を共有したい
内容
● Cactiとは● グラフの見方一般編● Percona MySQL Monitoring Template
● MySQLグラフ詳解● トラブルシューティングのケース● クエリのチューニング● InnoDB I/O チューニング
● まとめ
CactiとはWikipedia より http://ja.wikipedia.org/wiki/Cacti
“CactiはWebベースのネットワーク監視及びグラフ生成用オープンソースソフトウェアである。 指定間隔でポーリングし得られたデータをグラフ化する機能があり...”
NagiosCactiZabbixモニタリング御三家
インストール
● さくらのナレッジの「モニタリングツール「Cacti」でのリソース監視」がよくまとまっています http://knowledge.sakura.ad.jp/tech/618/
● 他にも入れてみた、使ってみた系の記事は多数
● 著名なプロジェクトなのにわりとバグが多いので、誰か上手く動いているのと同じバージョンにしてみたり、フットワーク軽めに対応するのがコツ
● epel のパッケージを yum で入れて依存パッケージの解決をさせてから、公式の最新 tar ボールを別ディレクトリにダウンロードして入れたりなどの方法もおススメ
データ取得とグラフ化の仕組み
MySQL管理データ
デバイス
snmp / ssh
● コマンド実行● 状態値取得
poller.php
rrdデータ
rrdtool
Web UI
Cactiサーバー
● Poller.php が定期的に snmp, ssh でデバイスから値を取得● rrdtool が round robin DB(rrd) にデータを格納● Web UI からのリクエストに応じて rrdtool がデータをグラフ化し画像を生成する
設定は充実のテンプレートで
● デバイスへアクセスしてグラフを生成するまでの設定● これら一から作成するのは大変● 用意されたテンプレートがあるので通常はそれを使います
(デモ http://127.0.0.1:10080/cacti/ )
グラフの見方一般編
100 mili(ミリ)です
現在値のグラフで、データは整数秒のみのハズなのに、800m とか30m とかグラフにありますが、これは何? ポーリング間隔が5分なので、その平均ですか?
RRDtool によるグラフの補正です
単位の G(ギガ), M(メガ), K (キロ)はよいとして、100m とかの m って何?
グラフの見方一般編
RRDtool によるサンプリング値の補正
0
1
時間
ポーリング
実際の値
グラフの見方一般編
0
1
時間
測定した値
RRDtool によるサンプリング値の補正
グラフの見方一般編
0
1
時間
RRDtool によるサンプリング値の補正
グラフの見方一般編
0
1
時間
RRDtool によるサンプリング値の補正
Percona MySQL Monitoring Template
MySQL の教育やコンサルティングを行う Percona 社はMySQLをフォークした Percona サーバーや、XtraDB Cluster, TokuDB など多彩な MySQL 関連製品も扱っています
オープンソースで無償で利用可能な以下のツール
Percona toolkitMySQL のスロークエリログの分析ツール pt-query-digest
Perconoa Monitoring PluginsCacti、Nagios, Zabbix のテンプレートを提供
Percona MySQL Monitoring Template
Percona MySQL グラフの読み方
例1 サーバーステータス変数をグラフ化したものQuestions と Com ~
公式リファレンスに説明があります
http://dev.mysql.com/doc/refman/5.6/ja/server-status-variables.html
例 Questions“サーバーによって実行されたステートメントの数。これは Queries 変数とは異なり、クライアントによってサーバーに送信されたステートメントのみを含み、ストアドプロシージャー内で実行されたステートメントは含みません“
Percona MySQL グラフの読み方
例2 Percona テンプレートのオリジナル項目
Uncheckpointed Bytes
SHOW STATUS にはありません(MySQLのリファレンスにもない)
Cactiインストールディレクトリ /scripts/ss_get_mysql_stats.php を読み解くと
- - -LOG- - -Log sequence number 12295546428Log flushed up to 12295546428Last checkpoint at 12295533453
SHOW ENGINE INNODB STATUS の(Log sequence number) – (Last checkpoint at) = Uncheckpointed_Bytes
MySQLはこれだけみれば大丈夫!グラフ詳解
● トラブルシューティングのケース● MySQL Command Counters● InnoDB Current Lock Waits● MySQL Transaction Hundler
● クエリのチューニング● MySQL Select Types● MySQL Handlers
● システム、I/O回りのチューニング● InnoDB Checkpoint Age
これだけみればというツボなグラフたち
トラブルシューティングのケース
● MySQL Command Counters で全体を観察クエリほぼ一定で
Questions だけ急増システムも重かった
● クエリでないSQL文というと、、、SET NAMES utf8;USE database;BEGIN; COMMIT; など補助的なもの。
● クエリ本体以外は完了している● リトライ?
トラブルシューティングのケース
● InnoDB Current Lock Wait でロックの量を知る
同じサーバーでQuestions だけ急増
したのと同じところ
Innodb Lock Wait SecsSHOW ENGINE INNODB STATUS で表示されるトランザクション情報のうち、”TRX HAS BEEN WAITING n SEC FOR THIS LOCK TO BE GRANTED” の n をシステムのトランザクション全部で合計したもの
デッドロック? 違ったシステム全体のロック待ち増加
トラブルシューティングのケース
● MySQL Transaction Handler でロールバックを探せ
同じサーバーでQuestions, Lockが
増えたところ
普段ほゼロな Handler Rollback が増加
ロールバックされ、アプリによるリトライによってトランザクションが多数再投入され、ロックはとりつつ、またロールバック、こうした挙動を繰り返していたもののと推察
ここからはアプリ開発チームと相談して調査!
クエリのチューニング
● MySQL Select Types でアプリのSELECTの書き方を判定テーブルまたはインデックスで
● Select Rangewhere で範囲を制限してselect
● Select Scan全件検索
Select Range の割合 >> Select Scan の割合 が望ましいのでこれは NG
クエリのチューニング
● MySQL Select Types
m(ミリ) なのでグラフでは見えませんが
● 「JOIN するときはインデックス使って行う」 という鉄則● 誰か破ったやつ(クエリ)がいるぞ!!!
クエリのチューニング
● MySQL Handler でI/O量を把握MySQL セッションまわりクエリ実行計画最適化
KVS的Handler 命令
ストレージエンジンデータ操作
クエリのチューニング
● Handler Read First テーブルやインデックスの全件検索スキャンで最初に先頭レコードの取得を行います。その回数。少ないほうが良い
● Handler Read Key インデックスのキー値に基づいて行を読んだ回数。● Handler Read Next キー値に基づいて行を特定した後、後続の行を読んだ回数。● Handler Read Prev キー値で行を決めた後、その前の行を取得した回数。● Handler Read Rnd InnoDB でプライマリキーの値を指定して1行読んだ回数。
ディスクへのアクセス方法がシーケンシャルアクセスではなくランダムアクセスということで、MySQL の世界では歴史的にピンポイントで1行読み込む動作に Random Read という用語
● Handler Read Rnd Next Read Rnd によって行を読んだ後、後続行を読み取った回数。
● Read Key < Read Next インデックス使っていても範囲で読み込みしている● Read Rnd < Read Rnd Next Rnd Next の比率が高いと、プライマリキーを使っていても広範に読んでいるのでやはりよくない傾向
グラフの形で観察できます!!!
クエリのチューニング
●前出の MySQL Handler グラフだと
Read Next で読み込んだ回数が圧倒的なので、インデックスを使った範囲読み込みの割合が多いことがわかります
システム、I/O回りのチューニング
InnoDB ディスクI/O のしくみ (InnoDB ログファイル)
123
更新データ
MySQLのメモリ InnoDB ログファイル
● 連続データをシリアルにディスクに書き込むので非常に高速● 磁気ディスクでも SSD のランダム書き込みより速い● バッファなどありますが、常時ディスクに書いている(というイメージ)● ログファイルに書いて更新トランザクション終了(というイメージ)● 最大 4GB (MySQL 5.5), 512GB (MySQL 5.6+)
システム、I/O回りのチューニング
InnoDB ディスクI/O のしくみ (InnoDB データファイル)
23
更新データ
MySQLのメモリ InnoDB データファイルバッファープール
1 テーブル インデックス
23 123 121 3
● バッファープールに格納するところまでで更新終了● 後続クエリの更新はメモリ上で完結● まとめてディスクに書き出す(チェックポイント)● データ量も多く、チェックポイントは重い処理● 速度は メモリ > Fusion-io > SSD > 磁気ディスク > 仮想ディスク
システム、I/O回りのチューニング
InnoDB ディスクI/O のしくみ (InnoDB データファイル)
ログファイル バッファープール
今、更
新が
ここ
メモリのみに更新データ
ログファイルで消えないデータ確保
データファイル
というのは許されない
全ての更新トランザクションを止めてでもディスクへの書き出しを行う
この量が Checkpoint Age
システム、I/O回りのチューニング
InnoDB ディスクI/O のしくみ (InnoDB データファイル)
Fuzzy Checkpoint● 定期的に常時発動● バッファープール上の古いダーティページから1回あたり少量の書き出しを行う● (アイドル時に書き出しが行われていくのはこのしくみ)
Sharp Checkpoint● ログファイルサイズの閾値(75~90%)を超えると発動し全てのダーティページを書き出す● ログファイルサイズが大きいとディスクのWrite量も多くなり高負荷● 磁気ディスクだとさらに高負荷● Write 中でも更新は来ますが速度で負けて 100% になるとトランザクションは受付停止
Adaptive Flushing (MySQL5.6+)● 更新量が少ない段階から、ある程度の書き出しを定期的に追加で行う仕組み● SSDなど高速ディスクであれば Sharp Checkpoint の回避で利点が多い● 低速ディスクだと低負荷なのに定期的に遅延が発生する原因となることも● デフォルトON
MySQLはこれだけみれば大丈夫!グラフ詳解
● ツボ中のツボ InnoDB ログファイル見積もり
ログファイル 128MB など
バッファープール (サーバーのメモリの6-8割)
安全第一法:クラッシュ時の処理も考慮してログファイルサイズほどほど
利点:● クラッシュ時のリカバリも可能● ときどき Sharp Checkpoint が発生するが量が少ないので処理のインパクトが小さい● 1日の更新量を正確に予測しなくてよい
欠点:ディスクへの書き込みが時々発生するので瞬間パフォーマンスは最大値ではない
MySQLはこれだけみれば大丈夫!グラフ詳解
● ツボ中のツボ InnoDB ログファイル見積もり
ログファイル
バッファープール (サーバーのメモリの6-8割)
ハイリスクハイリターン法: ログファイルサイズはバッファープールと同等に
利点:● 上手く見積もれば、長時間、データはログとメモリ上だけで動作
欠点:● クラッシュ時の処理は現実的には終わらないことも● 更新量予測を誤ると、長いトランザクション停止(数分〜)が発生して絶大なダメージ● 磁気ディスクでAdaptive Flushing を使うと低負荷なのに頻繁にレスポンス悪化
MySQLはこれだけみれば大丈夫!グラフ詳解
● ツボ中のツボ InnoDB Checkpoint Age
● SSD や Fusion-io などの高速ディスクを使っていない● 仮想サーバーでディスクも仮想ディスクか良くて磁気ディスク● 仮想といってもメモリは大きい
● MySQL 5.5 ないし ● MySQL 5.6 + InnoDB Adaptive Flushing = OFF を使いましょう
MySQLはこれだけみれば大丈夫!グラフ詳解
● ツボ中のツボ InnoDB Checkpoint Age
● バッファプール上に更新が溜まる速度に対して、fuzzy checkpoint が打ち勝っている状態● I/O の能力を使い切っていないのでまだ更新増やせそう
MySQLはこれだけみれば大丈夫!グラフ詳解
● ツボ中のツボ InnoDB Checkpoint Age
Sharp checkpoint がおこなわれているがすぐ打ち勝っているので影響なし
● Sharp Checkpoint が断続的に● ディスクの能力を存分に発揮している状態● I/O 負荷による微小な遅延がアプリに影響出ていないか確認しましょう
MySQLはこれだけみれば大丈夫!グラフ詳解
● ツボ中のツボ InnoDB Checkpoint Age
● 水平線になった場合 sharp checkpoint が常時走っている状態● ディスクの性能をフルに発揮している状態● Checkpoint Age 100%到達時のトランザクション停止が微小で済んでいるか、長時
間に及んでいるか、グラフでは区別がつきません● 必ずアプリケーションのログで確認しましょう
まとめ
● 1秒未満のクエリ実行時間に対しCactiのグラフはポーリング(5分)単位ですが、それでも見えてくるものはたくさんあります
● Cacti での MySQL のパフォーマンス監視に今回紹介したツボをご活用ください!!!