MySQLステータスモニタリング
- 7. ＼こんに千葉／ (c)hokke̲mirin yoku0825 オラクれない- ポスグれない- マイエスキューエる- ⽣息域 Twitter: @yoku0825- Blog: ⽇々の覚書- MyNA ML: ⽇本MySQLユーザ会- MySQL Casual: Slack- 6/54
- 10. ステータスモニタリングで思うこと 有意義な 情報がほしい なるべく ⼿間はかけたくない 平たく⾔うとデータソース取得メソッドは⾃分で書きたくない もっと⾔うと SHOW ENGINE INNODB STATUS を正規表現でパースしたくない - ビバ エコシステム- しなくていいなら 運⽤したくない どうせなら フロントエンドはイケてる⽅がいい 9/54
- 12. PMM 11/54
- 13. Mackerel 12/54
- 15. 家族思いだし、 14/54
- 17. 閑話休題 16/54
- 18. ステータスモニタリングで思うこと(again) 有意義な 情報がほしい なるべく ⼿間はかけたくない 平たく⾔うとデータソース取得メソッドは⾃分で書きたくない もっと⾔うと SHOW ENGINE INNODB STATUS を正規表現でパースしたくない - ビバ エコシステム- しなくていいなら 運⽤したくない どうせなら フロントエンドはイケてる⽅がいい 17/54
- 19. だがしか し 18/54
- 22. MySQLのステータスはどこで⾒る︖ SHOW ステートメント派 SHOW GLOBAL STATUS- SHOW PROCESSLIST- SHOW ENGINE INNODB STATUS- SHOW SLAVE STATUS- SHOW TABLE STATUS- information_schema, performance_schema 派 i̲s.tables, i̲s.innodb̲metrics, i̲s.global̲status, ..- p̲s.table̲io̲waits̲summary̲by̲table, p̲s.threads, p̲s.events̲statements̲summary̲by̲digest, .. - 21/54
- 23. SHOW ステートメント ⼀応SQL 結果セットはカラムと⾏から成るフツーのSQLと同じ結果セ ット フツーに⽣DBIでもORMでもアクセスできる- ただし SHOW ENGINE INNODB STATUS は 1⾏3カラムの結果セットで、 “Status” カラムの中にテキストで⼊ってるからパース地獄 - 細かいことを⾔うと information̲schema の仲間 22/54
- 24. SHOW vs i̲s / p̲s i̲s, p̲sへのアクセスは完全なSQL SHOW にも LIKE や WHERE が書けるけど、 ORDER BY, GROUP BY には対 応していない - SELECTアクセスが基本な奴らだから（︖）変にパースを要 求するものが あんまり ない たまにある- 23/54
- 25. SHOW vs i̲s / p̲s SHOW GLOBAL STATUS information̲schema.GLOBAL̲STATUS(*), performance̲schema.global̲status SHOW PROCESSLIST information̲schema.PROCESSLIST, performance̲schema.threads SHOW ENGINE INNODB STATUS information̲schema.INNODB̲METRICS SHOW SLAVE STATUS performance̲schema.replication̲connection̲configuration, replication̲applier̲status̲by̲coordinator, .. SHOW TABLE STATUS information̲schema.TABLES 24/54
- 27. SHOW GLOBAL STATUS information̲schema.GLOBAL̲STATUS グローバルのステータスカウンターと、今⽣きている全てのthdのステータ スカウンターを ⾜し合わせて 表⽰する performance̲schema.global̲status 各thdがステータスカウンターをインクリメントする時ついでにp̲sがインク リメントされる 26/54
- 29. performance̲schema #とは イベントベースのプロファイラー インストゥルメントを通過するたびに performance_schema スキーマのテーブルに情報が蓄積される 機能の名前としての「パフォーマンススキーマ」、スキーマ の名前空間として「performance̲schemaスキーマ(データ ベース)」、パフォーマンススキーマの情報を格納する専⽤ の「performance̲schemaストレージエンジン」があるの がややこしい オンメモリーストレージエンジンなので永続化はしない- 記録に特化しているので参照は地味に遅い（MySQL 8.0で良くなるら しい） - i̲sだったら「刺さったか︕︖」と思うくらい待たされても、p̲sは刺 さってなくて単に重いだけの場合が多い - 28/54
- 30. information̲schema vs performance̲schema i̲sはMySQL 5.1のInnoDB Plugin以降だんだん便利に INNODB̲TRXとかINNODB̲LOCK̲WAITSとかべんり- 地味にMySQL 5.6とそれ以降で追加されているものは⾊々楽しい- p̲sは5.6で急に開花した 実装としてはMySQL 5.5からあったけど5.5のp̲sは（我々目線で は）使いようがなかった - 5.6から低オーベーヘッド、省メモリーで「ジャンキー向け機能」か ら「⼀般的なモニタリングに使えるように」 MySQL 5.5まではエージェント型だったMySQL Enterprise Monitorも5.6とそれ以 降はp̲sを使ってエージェントレスになったことだし - 29/54
- 31. たとえばテーブルサイズ innodb_stats_on_metadata= 0 にすること︕ （5.6とそれ以 降はデフォルトで0） LIMITはお好みで。⼤概、トップ20とか30とか取って置け ば⾜りると思う i̲sだからもちろん誤差はある。リアルタイムな値じゃなく てデイリーやウィークリーで⼗分 30/54
- 32. たとえばテーブルサイズ mysql> SELECT CONCAT(table_schema, '.', table_name) AS table_name, -> table_rows, data_length + index_length AS table_size, -> data_free, COALESCE(auto_increment, 0) AS auto_increment -> FROM information_schema.tables -> ORDER BY table_size DESC -> LIMIT 10; +-------------+------------+------------+-----------+----------------+ | table_name | table_rows | table_size | data_free | auto_increment | +-------------+------------+------------+-----------+----------------+ | fe.bbb18c90 | 25224307 | 4578082816 | 7340032 | 27979876 | | fe.34579d37 | 18991963 | 2065661952 | 4194304 | 19482172 | | fe.61c622dc | 21195791 | 1474297856 | 7340032 | 21744792 | | fe.78e73102 | 4285220 | 1121239040 | 5242880 | 4179815 | | fe.4b581bb9 | 4167617 | 706543616 | 5242880 | 4179816 | | fe.faaafde9 | 4588106 | 538378240 | 5242880 | 4598839 | | fe.5ae66d4a | 4117296 | 501055488 | 4194304 | 4127825 | | fe.652f200b | 4169485 | 453672960 | 5242880 | 0 | | fe.8363482f | 4169357 | 432095232 | 6291456 | 0 | | fe.9287128c | 2127303 | 265158656 | 7340032 | 2132172 | +-------------+------------+------------+-----------+----------------+ 10 rows in set (0.04 sec) 31/54
- 34. たとえばspin̲rounds mysql> SELECT name, count -> FROM information_schema.innodb_metrics -> WHERE name LIKE '%spin%'; +------------------------------+------------+ | name | count | +------------------------------+------------+ | innodb_rwlock_s_spin_waits | 0 | | innodb_rwlock_x_spin_waits | 0 | | innodb_rwlock_sx_spin_waits | 381205234 | | innodb_rwlock_s_spin_rounds | 1865126843 | | innodb_rwlock_x_spin_rounds | 9173666588 | | innodb_rwlock_sx_spin_rounds | 6758611710 | +------------------------------+------------+ 6 rows in set (0.00 sec) 33/54
- 37. たとえばInnoDBバッファプールの内訳 mysql> SELECT table_name, index_name, -> SUM(number_records) AS records, SUM(data_size) AS data_size -> FROM information_schema.innodb_buffer_page -> WHERE table_name NOT LIKE 'mysql%' -> GROUP BY table_name, index_name -> ORDER BY data_size DESC -> LIMIT 10; +-----------------+------------+---------+-----------+ | table_name | index_name | records | data_size | +-----------------+------------+---------+-----------+ | `7f`.`c3bc5a32` | e428d370 | 9841761 | 226620867 | | `7f`.`c3bc5a32` | 54c2815f | 8066893 | 104999661 | | `7f`.`c3bc5a32` | 88540e9a | 6926166 | 131772542 | | `7f`.`c3bc5a32` | 462a1d8a | 4406127 | 83872645 | | `7f`.`5af9ce85` | d52e82c1 | 3528078 | 60115390 | | `7f`.`c3bc5a32` | PRIMARY | 3213476 | 115271756 | | `7f`.`c3bc5a32` | 44c576bb | 3148514 | 59895974 | | `7f`.`303a176f` | 1cbc573f | 2307297 | 43961563 | | `7f`.`303a176f` | 25b1bd38 | 2067966 | 43606310 | | `7f`.`dd50ab9f` | 88f49848 | 1816568 | 34545024 | +-----------------+------------+---------+-----------+ 10 rows in set (2.44 sec) 36/54
- 38. たとえばテーブルアクセスの読み書きレイテンシー これ累計なので、累計のままストアするか差分にしてストア するかは好み Mackerelは累計値で投げてもグラフ側で差分描写にできて いいなあ 37/54
- 39. たとえばテーブルアクセスの読み書きレイテンシー mysql> SELECT CONCAT(object_schema, '.', object_name) AS object, -> count_read, count_write, avg_timer_read, avg_timer_write -> FROM performance_schema.table_io_waits_summary_by_table -> WHERE object_schema NOT IN ('mysql', 'performance_schema', 'sys') -> ORDER BY count_star DESC -> LIMIT 10; +-------------+------------+-------------+----------------+-----------------+ | object | count_read | count_write | avg_timer_read | avg_timer_write | +-------------+------------+-------------+----------------+-----------------+ | fe.3dbf1566 | 18869612 | 17539638 | 13651880 | 20003808 | | fe.5cf383d7 | 6068739 | 6069827 | 23701018 | 62976298 | | fe.61c622dc | 0 | 3632649 | 0 | 41433832 | | fe.34579d37 | 0 | 3328275 | 0 | 116323548 | | fe.3b92ebab | 1071450 | 1089281 | 22963248 | 66586982 | | fe.8363482f | 671311 | 1122995 | 41658716 | 97360142 | | fe.5ae66d4a | 467985 | 1095348 | 48890534 | 102864366 | | fe.bbb18c90 | 6 | 1153540 | 31729962 | 143108570 | | fe.ee11cbb1 | 466088 | 468043 | 45651870 | 49815150 | | fe.faaafde9 | 0 | 769627 | 0 | 125484436 | +-------------+------------+-------------+----------------+-----------------+ 10 rows in set (0.01 sec) 38/54
- 42. たとえばクエリーダイジェスト mysql> SELECT SUBSTR(digest_text, 1, 20) AS digest_text, -> count_star, sum_timer_wait, sum_rows_examined, sum_rows_sent -> FROM performance_schema.events_statements_summary_by_digest -> WHERE DIGEST IS NOT NULL AND -> count_star > 500 -> LIMIT 10; +----------------------+------------+------------------+-------------------+---------------+ | digest_text | count_star | sum_timer_wait | sum_rows_examined | sum_rows_sent | +----------------------+------------+------------------+-------------------+---------------+ | SELECT @@`version_co | 137289 | 25436857660000 | 0 | 137289 | | SHOW SLAVE STATUS | 366546 | 112342782225000 | 0 | 0 | | BEGIN | 13485295 | 575528569805000 | 0 | 0 | | INSERT INTO `user_el | 627445 | 89789157785000 | 0 | 0 | | SHOW MASTER LOGS | 229235 | 27056745066000 | 0 | 0 | | SHOW PROCESSLIST | 229243 | 14607003138000 | 0 | 0 | | SHOW ENGINE `INNODB` | 229239 | 123289626548000 | 0 | 0 | | INSERT INTO `history | 525090 | 158209504507000 | 0 | 0 | | INSERT INTO `user_di | 338137 | 121445307222000 | 0 | 0 | | INSERT INTO `history | 3328275 | 1085911891224000 | 0 | 0 | +----------------------+------------+------------------+-------------------+---------------+ 10 rows in set (0.00 sec) 41/54
- 47. 今使ってるヤーツ 46/54
- 48. 今のヘーシャのステータスモニタリング(?) メインはPMP for Cacti 深く監視するにはお⼿製スクリプト（Perl） データはそれ⽤のMySQLに格納してあるので、必要に応じてre:dash でグラフにする - ⼀周回って「これをCactiに⾷わせればいいんじゃないか」とか「パー ジするデータはrrdtoolに⼊れちゃえばいいんじゃないか」とか思って きた - ショットでモニタリングしたい時はPMM PMM ServerはDocker image- PMM Agentはrpmで⼊れる- 47/54
- 49. それぞれに思うこと PMP for Cacti フロントエンドとデータソースメソッドが両⼊りなので⼿間のかからなさと 網羅率はいい。拡張が⾯倒 お⼿製Perl フロントエンドを別に⽤意しなければいけないのがちょっと⾯倒。おとなし くre:dashを真⾯目に運⽤すればいいのかも知れない anemo eat er ステータス監視じゃないけどスローログを⾷って可視化するヤーツ PMM ワンショットで使う分には最⾼。容量効率とPMM Serverがブラックボック ス過ぎるのがネック 余談だけどお⼿製Perlの記録⽤MySQLは8.0にしたくて、8.0にして窓関数使えれば⾃分で差を取らなくてもSQL（re:dash側）だけで捗りそう 48/54
- 50. 気に⼊っているところ どれも吊るしのMySQLから情報が取れる performance̲schemaはMySQL 5.6以降デフォルトでON パラメーター何もいじらなくてもそれなりに情報が取れる- innodb̲metricsをガリガリ使いたいなら innodb_monitor_enable = all だがしかしどちらも実質5.6から 49/54
- 51. おかげさまで +---------+-------+ | version | count | +---------+-------+ | 4.0 | 2 | | 5.0 | 38 | | 5.1 | 17 | | 5.5 | 22 | | 5.6 | 126 | | 5.7 | 106 | +---------+-------+ 50/54
- 52. ほら 51/54