Osc2015北海道札幌my sql勉強会_波多野_r3

これだけみれば大丈夫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モニタリング御三家

http://ja.wikipedia.org/wiki/Cacti

インストール

● さくらのナレッジの「モニタリングツール「Cacti」でのリソース監視」がよくまとまっています　http://knowledge.sakura.ad.jp/tech/618/

● 他にも入れてみた、使ってみた系の記事は多数

● 著名なプロジェクトなのにわりとバグが多いので、誰か上手く動いているのと同じバージョンにしてみたり、フットワーク軽めに対応するのがコツ

● epel のパッケージを yum で入れて依存パッケージの解決をさせてから、公式の最新 tar ボールを別ディレクトリにダウンロードして入れたりなどの方法もおススメ

http://knowledge.sakura.ad.jp/tech/618/

データ取得とグラフ化の仕組み

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/ ）

http://127.0.0.1:10080/cacti/

グラフの見方一般編

100 mili（ミリ）です

現在値のグラフで、データは整数秒のみのハズなのに、800m とか30m とかグラフにありますが、これは何？ポーリング間隔が5分なので、その平均ですか？

RRDtool によるグラフの補正です

単位の G（ギガ）, M（メガ）, K （キロ）はよいとして、100m とかの m って何？


RRDtool によるサンプリング値の補正

0

1

時間

ポーリング

実際の値


0

1

時間

測定した値



0

1

時間



0

1

時間


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 の世界では歴史的にピンポイントで１行読み込む動作に 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+)


InnoDB ディスクI/O のしくみ　（InnoDB データファイル）

23

更新データ

MySQLのメモリ InnoDB データファイルバッファープール

1 テーブルインデックス

23 123 121 3

● バッファープールに格納するところまでで更新終了● 後続クエリの更新はメモリ上で完結● まとめてディスクに書き出す（チェックポイント）● データ量も多く、チェックポイントは重い処理● 速度は　メモリ > Fusion-io > SSD > 磁気ディスク > 仮想ディスク



ログファイルバッファープール

今、更

新が

ここ

メモリのみに更新データ

ログファイルで消えないデータ確保

データファイル

というのは許されない

全ての更新トランザクションを止めてでもディスクへの書き出しを行う

この量が Checkpoint Age



Fuzzy Checkpoint● 定期的に常時発動● バッファープール上の古いダーティページから1回あたり少量の書き出しを行う● （アイドル時に書き出しが行われていくのはこのしくみ）

Sharp Checkpoint● ログファイルサイズの閾値(75～90%)を超えると発動し全てのダーティページを書き出す● ログファイルサイズが大きいとディスクのWrite量も多くなり高負荷● 磁気ディスクだとさらに高負荷● Write 中でも更新は来ますが速度で負けて 100% になるとトランザクションは受付停止

Adaptive Flushing (MySQL5.6+)● 更新量が少ない段階から、ある程度の書き出しを定期的に追加で行う仕組み● SSDなど高速ディスクであれば Sharp Checkpoint の回避で利点が多い● 低速ディスクだと低負荷なのに定期的に遅延が発生する原因となることも● デフォルトON


● ツボ中のツボ InnoDB ログファイル見積もり

ログファイル　128MB など

バッファープール　（サーバーのメモリの6－8割）

安全第一法：クラッシュ時の処理も考慮してログファイルサイズほどほど

利点：● クラッシュ時のリカバリも可能● ときどき Sharp Checkpoint が発生するが量が少ないので処理のインパクトが小さい● １日の更新量を正確に予測しなくてよい

欠点：ディスクへの書き込みが時々発生するので瞬間パフォーマンスは最大値ではない


● ツボ中のツボ InnoDB ログファイル見積もり

ログファイル　

バッファープール　（サーバーのメモリの6－8割）

ハイリスクハイリターン法：　ログファイルサイズはバッファープールと同等に

利点：● 上手く見積もれば、長時間、データはログとメモリ上だけで動作

欠点：● クラッシュ時の処理は現実的には終わらないことも● 更新量予測を誤ると、長いトランザクション停止（数分〜）が発生して絶大なダメージ● 磁気ディスクでAdaptive Flushing を使うと低負荷なのに頻繁にレスポンス悪化


● ツボ中のツボ InnoDB Checkpoint Age

　● SSD や Fusion-io などの高速ディスクを使っていない● 仮想サーバーでディスクも仮想ディスクか良くて磁気ディスク● 仮想といってもメモリは大きい

● MySQL 5.5 ないし ● MySQL 5.6 + InnoDB Adaptive Flushing = OFF を使いましょう



　

● バッファプール上に更新が溜まる速度に対して、fuzzy checkpoint が打ち勝っている状態● I/O の能力を使い切っていないのでまだ更新増やせそう



　Sharp checkpoint がおこなわれているがすぐ打ち勝っているので影響なし

● Sharp Checkpoint が断続的に● ディスクの能力を存分に発揮している状態● I/O 負荷による微小な遅延がアプリに影響出ていないか確認しましょう



　

● 水平線になった場合 sharp checkpoint が常時走っている状態● ディスクの性能をフルに発揮している状態● Checkpoint Age 100%到達時のトランザクション停止が微小で済んでいるか、長時

間に及んでいるか、グラフでは区別がつきません● 必ずアプリケーションのログで確認しましょう

まとめ

　 ● １秒未満のクエリ実行時間に対しCactiのグラフはポーリング(5分)単位ですが、それでも見えてくるものはたくさんあります

● Cacti での MySQL のパフォーマンス監視に今回紹介したツボをご活用ください!!!

Technology

Osc2015北海道 札幌my sql勉強会_波多野_r3

Osc2015北海道札幌my sql勉強会_波多野_r3