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

Transcript

• 1. これだけみれば大丈夫 Cact i によるMySQLパフォーマンス監視のツボ 日本MySQLユーザー会 波多野　信広　（札幌MySQL勉強会） 2015/ 06/ 13 r2
• 2. 自己紹介 ● 波多野　信広 ( t wi t t er @nobuHat ano) ● 日本MySQLユーザー会 ( 札幌MySQL勉強会) ● 1969年生まれ ● 好きなもの SF、ゲーム、美術鑑賞 ● 超並列サーバーのハード／ソフトサポートを十 数年 ● 札幌のI T企業のインフラとしてMySQL歴三年
• 3. 札幌MySQL勉強会 ● MySQLに関することなら幅広く ● たまにしか集まってませんが、 ちゃんと勉強してます！
• 4. この話の目的 ● MySQL超メジャーなのに、モニタリングのグラフ の意味や内容を調べようとググっても見つから ない ● しかたなく自分で実戦の中で調べて来てわかっ たことが ● せっかくなので経験を共有したい
• 5. 内容 ● Cact i とは ● グラフの見方一般編 ● Per cona MySQL Moni t or i ng Templ at e ● MySQLグラフ詳解 ● トラブルシューティングのケース ● クエリのチューニング ● I nnoDB I / O チューニング ● まとめ
• 6. Cact i とは Wi ki pedi a より ht t p: / / j a. wi ki pedi a. or g/ wi ki / Cact i “ Cact i はWebベー スのネットワーク 監視及びグラフ生 成用オープンソー スソフトウェアで ある。 指定間隔で ポーリングし得ら れたデータをグラ フ化する機能があ り. . . ” Nagi os Cact i Zabbi x モニタリング御 三家
• 7. インストール ● さくらのナレッジの「モニタリングツール「Cact i 」でのリソー ス監視」がよくまとまっています　 ht t p: / / knowl edge. sakur a. ad. j p/ t ech/ 618/ ● 他にも入れてみた、使ってみた系の記事は多数 ● 著名なプロジェクトなのにわりとバグが多いので、誰か上手く動 いているのと同じバージョンにしてみたり、フットワーク軽めに 対応するのがコツ ● epel のパッケージを yum で入れて依存パッケージの解決をさ せてから、公式の最新 t ar ボールを別ディレクトリにダウン ロードして入れたりなどの方法もおススメ
• 8. データ取得とグラフ化の仕組み MySQL 管理データ デバイス snmp / ssh ● コマンド実行 ● 状態値取得 pol l er . p hp r r d データ r r dt oo l Web UI Cact i サーバー ● Pol l er . php が定期的に snmp, ssh でデバイスから 値を取得 ● r r dt ool が r ound r obi n DB( r r d) にデータを格納 ● Web UI からのリクエストに応じて r r dt ool がデー タをグラフ化し画像を生成する
• 9. 設定は充実のテンプレートで ● デバイスへアクセスしてグラフを生成するまで の設定 ● これら一から作成するのは大変 ● 用意されたテンプレートがあるので通常はそれ を使います （デモ ht t p: / / 127. 0. 0. 1: 10080/ cact i / ）
• 10. グラフの見方一般編 100 mi l i （ミリ）で す 現在値のグラフで、データは整数秒のみのハズなの に、800m とか30m とかグラフにありますが、これは 何？ ポーリング間隔が5分なので、その平均ですか？ RRDt ool によるグラフの補正で す 単位の G（ギガ）, M（メガ）, K （キロ）はよいとし て、100m とかの m って何？
• 11. グラフの見方一般編 RRDt ool によるサンプリング値の補 正 0 1 時間 ポーリング 実際の値
• 12. グラフの見方一般編 0 1 時間 測定した値 RRDt ool によるサンプリング値の補 正
• 13. グラフの見方一般編 0 1 時間 RRDt ool によるサンプリング値の補 正
• 14. グラフの見方一般編 0 1 時間 RRDt ool によるサンプリング値の補 正
• 15. Per cona MySQL Moni t or i ng Templ at e MySQL の教育やコンサルティングを行う Per cona 社は MySQLをフォークした Per cona サーバーや、Xt r aDB Cl ust er , TokuDB など多彩な MySQL 関連製品も扱って います オープンソースで無償で利用可能な以下のツール Per cona t ool ki t MySQL のスロークエリログの分析ツール pt - quer y- di gest Per conoa Moni t or i ng Pl ugi ns Cact i 、Nagi os, Zabbi x のテンプレートを提供
• 16. Per cona MySQL Moni t or i ng Templ at e
• 17. Per cona MySQL グラフの読み方 例1　サーバーステータス変数をグラフ化したも の Quest i ons と Com ～ 公式リファレンスに説明があ ります ht t p: / / dev. mysql . com/ doc/ r ef man/ 5. 6/ j a/ ser ver - st at us- var i abl es. ht ml 例 Quest i ons “サーバーによって実行されたステートメントの数。これは Quer i es 変数とは異なり、 クライアントによってサーバーに送信されたステートメントのみを含み、ストアドプロ シージャー内で実行されたステートメントは含みません“
• 18. Per cona MySQL グラフの読み方 例2　Percona テンプレートのオリジナル項目 Uncheckpoi nt ed Byt es SHOW STATUS にはありません （MySQLのリファレンスにもな い） Cact i インストールディレクトリ / scr i pt s/ ss_get _mysql _st at s. php を読み解 - - - LOG - - - Log sequence number 12295546428 Log f l ushed up t o 12295546428 Last checkpoi nt at 12295533453 SHOW ENGI NE I NNODB STATUS の ( Log sequence number ) – ( Last checkpoi nt at ) = Uncheckpoi nt ed_Byt es
• 19. MySQLはこれだけみれば大丈夫！ グラフ詳解 ● トラブルシューティングのケース ● MySQL Command Count er s ● I nnoDB Cur r ent Lock Wai t s ● MySQL Tr ansact i on Hundl er ● クエリのチューニング ● MySQL Sel ect Types ● MySQL Handl er s ● システム、I / O回りのチューニング ● I nnoDB Checkpoi nt Age これだけみればというツボなグラフ たち
• 20. トラブルシューティングのケース ● MySQL Command Count er s で全体を観察 クエリほぼ一定で Questions だけ急増 システムも重かった ● クエリでないSQL文という と、、、 SET NAMES ut f 8; USE dat abase; BEGI N; COMMI T; など補助的なもの。 ● クエリ本体以外は完了して いる ● リトライ？
• 21. トラブルシューティングのケース ● I nnoDB Cur r ent Lock Wai t 　でロックの量を知る 同じサーバーで Quest i ons だけ急増 したのと同じところ I nnodb Lock Wai t Secs SHOW ENGI NE I NNODB STATUS で表示されるトランザクション情報のう ”ち、 TRX HAS BEEN WAI TI NG n SEC FOR THI S LOCK TO BE GRANTED” の n をシステムのトランザクション全部で合計したもの デッドロッ ク？ 違ったシステム全体のロック 待ち増加
• 22. トラブルシューティングのケース ● MySQL Tr ansact i on Handl er でロールバックを探せ 同じサーバーで Quest i ons, Lockが 増えたところ 普段ほゼロな Handl er Rol l back が増加 ロールバックされ、アプリによるリトライによってトランザクション が多数再投入され、ロックはとりつつ、またロールバック、こうした 挙動を繰り返していたもののと推察 ここからはアプリ開発チームと相談して調 査！
• 23. クエリのチューニング ● MySQL Sel ect Types でアプリのSELECTの書き方を 判定 テーブルまたはイ ンデックスで ● Sel ect Range wher e で範囲 を制限して sel ect ● Sel ect Scan 全件検索 Sel ect Range の割合　>> Sel ect Scan の割合　　が望ましい のでこれは NG
• 24. クエリのチューニング ● MySQL Sel ect Types m( ミリ) なのでグラフ では見えませんが ● 「JOI N するときはインデックス使って行う」　という鉄則 ● 誰か破ったやつ（クエリ）がいるぞ！！！
• 25. クエリのチューニング ● MySQL Handl er でI / O量を把握 MySQL セッションまわり クエリ実行計画 最適化 KVS的 Handl er 命 令 ストレージエンジン データ操作
• 26. クエリのチューニング ● Handl er Read Fi rst テーブルやインデックスの全件検索スキャンで最初に先頭レ コードの取得を行います。その回数。少ないほうが良い ● Handl er Read Key インデックスのキー値に基づいて行を読んだ回数。 ● Handl er Read Next キー値に基づいて行を特定した後、後続の行を読んだ回数。 ● Handl er Read Prev キー値で行を決めた後、その前の行を取得した回数。 ● Handl er Read Rnd I nnoDB でプライマリキーの値を指定して1行読んだ回数。 ディスクへのアクセス方法がシーケンシャルアクセスではなくランダムアクセスということで、MySQL の世界 では歴史的にピンポイントで１行読み込む動作に Random Read という用語 ● Handl er Read Rnd Next Read Rnd によって行を読んだ後、後続行を読み取った 回数。 ● Read Key < Read Next インデックス使っていても範囲で読み込みしている ● Read Rnd < Read Rnd Next Rnd Next の比率が高いと、プライマリキーを使っ ていても広範に読んでいるのでやはりよくない傾向 グラフの形で観察できます！！！
• 27. クエリのチューニング ● 前出の MySQL Handl er グラフだと Read Next で読み 込んだ回数が圧倒的 なので、インデック スを使った範囲読み 込みの割合が多いこ とがわかります
• 28. システム、I / O回りのチューニング I nnoDB ディスクI / O のしくみ　（I nnoDB ログ ファイル） 123 更新データ MySQLのメモリ I nnoDB ログファイ ル ● 連続データをシリアルにディスクに書き込むので非常に 高速 ● 磁気ディスクでも SSD のランダム書き込みより速い ● バッファなどありますが、常時ディスクに書いている （というイメージ） ● ログファイルに書いて更新トランザクション終了（とい うイメージ） ● 最大 4GB ( MySQL 5. 5) , 512GB ( MySQL 5. 6+)
• 29. システム、I / O回りのチューニング I nnoDB ディスクI / O のしくみ　（I nnoDB デー タファイル） 23 更新データ MySQLのメモリ I nnoDB データファ イル バッファープール 1 テーブル インデッ クス 23 1 23 121 3 ● バッファープールに格納するところまでで更新終了 ● 後続クエリの更新はメモリ上で完結 ● まとめてディスクに書き出す（チェックポイント） ● データ量も多く、チェックポイントは重い処理 ● 速度は　メモリ > Fusi on- i o > SSD > 磁気ディスク > 仮 想ディスク
• 30. システム、I / O回りのチューニング I nnoDB ディスクI / O のしくみ　（I nnoDB データファイル） ログファイ ル バッファープー ル 今、更新がここ メモリのみに更新データ ログファイルで消えないデータ確保 データファイル というのは許されな い 全ての更新トランザ クションを止めてで もディスクへの書き 出しを行う この量が Checkpoi nt Age
• 31. システム、I / O回りのチューニング I nnoDB ディスクI / O のしくみ　（I nnoDB データファイル） Fuzzy Checkpoi nt ● 定期的に常時発動 ● バッファープール上の古いダーティページから1回あたり少量の書き出しを行 う ● （アイドル時に書き出しが行われていくのはこのしくみ） Shar p Checkpoi nt ● ログファイルサイズの閾値( 75～90%) を超えると発動し全てのダーティページ を書き出す ● ログファイルサイズが大きいとディスクのWr i t e量も多くなり高負荷 ● 磁気ディスクだとさらに高負荷 ● Wr i t e 中でも更新は来ますが速度で負けて 100% になるとトランザクション は受付停止 Adapt i ve Fl ushi ng ( MySQL5. 6+) ● 更新量が少ない段階から、ある程度の書き出しを定期的に追加で行う仕組み ● SSDなど高速ディスクであれば Shar p Checkpoi nt の回避で利点が多い ● 低速ディスクだと低負荷なのに定期的に遅延が発生する原因となることも ● デフォルトON
• 32. MySQLはこれだけみれば大丈夫！ グラフ詳解 ● ツボ中のツボ I nnoDB ログファイル見積もり ログファイル　128MB な ど バッファープール　（サーバーのメモリの6－8割） 安全第一法：クラッシュ時の処理も考慮してログファイルサイズほどほど 利点： ● クラッシュ時のリカバリも可能 ● ときどき Shar p Checkpoi nt が発生するが量が少ないので処理のインパ クトが小さい ● １日の更新量を正確に予測しなくてよい 欠点： ディスクへの書き込みが時々発生するので瞬間パフォーマンスは最大値ではな い
• 33. MySQLはこれだけみれば大丈夫！ グラフ詳解 ● ツボ中のツボ I nnoDB ログファイル見積もり ログファイル　 バッファープール　（サーバーのメモリの6－8割） ハイリスクハイリターン法： 　ログファイルサイズはバッファープールと同等に 利点： ● 上手く見積もれば、長時間、データはログとメモリ上だけで動作 欠点： ● クラッシュ時の処理は現実的には終わらないことも ● 更新量予測を誤ると、長いトランザクション停止（数分〜）が発生して絶大なダ メージ ● 磁気ディスクでAdapt i ve Fl ushi ng を使うと低負荷なのに頻繁にレスポンス 悪化
• 34. MySQLはこれだけみれば大丈夫！ グラフ詳解 ● ツボ中のツボ I nnoDB Checkpoi nt Age 　● SSD や Fusi on- i o などの高速ディスクを使っていない ● 仮想サーバーでディスクも仮想ディスクか良くて磁気ディスク ● 仮想といってもメモリは大きい ● MySQL 5. 5 ないし ● MySQL 5. 6 + I nnoDB Adapt i ve Fl ushi ng = OFF を使 いましょう
• 35. MySQLはこれだけみれば大丈夫！ グラフ詳解 ● ツボ中のツボ I nnoDB Checkpoi nt Age 　 ● バッファプール上に更新が溜まる速度に対して、f uzzy checkpoi nt が打ち勝って いる状態 ● I / O の能力を使い切っていないのでまだ更新増やせそう
• 36. MySQLはこれだけみれば大丈夫！ グラフ詳解 ● ツボ中のツボ I nnoDB Checkpoi nt Age 　 Shar p checkpoi nt がおこなわれているがす ぐ打ち勝っているので影 響なし ● Shar p Checkpoi nt が断続的に ● ディスクの能力を存分に発揮している状態 ● I / O 負荷による微小な遅延がアプリに影響出てい ないか確認しましょう
• 37. MySQLはこれだけみれば大丈夫！ グラフ詳解 ● ツボ中のツボ I nnoDB Checkpoi nt Age 　 ● 水平線になった場合 shar p checkpoi nt が常時走っている状態 ● ディスクの性能をフルに発揮している状態 ● Checkpoi nt Age 100%到達時のトランザクション停止が微小で済んでいる か、長時間に及んでいるか、グラフでは区別がつきません ● 必ずアプリケーションのログで確認しましょう
• 38. まとめ 　 ● １秒未満のクエリ実行時間に対しCact i のグ ラフはポーリング( 5分) 単位ですが、それで も見えてくるものはたくさんあります ● Cact i での MySQL のパフォーマンス監視に 今回紹介したツボをご活用ください! ! !