Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

MySQLステータスモニタリング

7,541 views

Published on

2017/07/14

Published in: Technology
  • Hello! Get Your Professional Job-Winning Resume Here - Check our website! https://vk.cc/818RFv
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

MySQLステータスモニタリング

  1. 1. MySQLステータスモニタリング 〜それ、Perlで(も)できるよ〜 2017/07/14 yoku0825 吉祥寺.pm 11
  2. 2. Chiba.pmの ⽅から来まし た 1/54
  3. 3. Chiba.pm の “m” は 2/54
  4. 4. MySQL の”M” :) 3/54
  5. 5. ※諸説あ ります 4/54
  6. 6. Ichikawa.pm まだ⾏ってなく てごめんなさい 5/54
  7. 7. \こんに千葉/ (c)hokke̲mirin yoku0825 オラクれない- ポスグれない- マイエスキューエる- ⽣息域 Twitter: @yoku0825- Blog: ⽇々の覚書- MyNA ML: ⽇本MySQLユーザ会- MySQL Casual: Slack- 6/54
  8. 8. MySQLステー タスモニタリ ング #とは 7/54
  9. 9. MySQLステータスモニタリング #とは ZabbixとかCloudWatch的な⾔い回しで “メトリクス監視” と呼んでるやつのつもり 俺はCactiスキー(単に他のを知らないとも) おや、そういえば今⽇はMackerelの中の⼈が…︖ 8/54
  10. 10. ステータスモニタリングで思うこと 有意義な 情報がほしい なるべく ⼿間はかけたくない 平たく⾔うとデータソース取得メソッドは⾃分で書きたくない もっと⾔うと SHOW ENGINE INNODB STATUS を正規表現でパースしたくない - ビバ エコシステム- しなくていいなら 運⽤したくない どうせなら フロントエンドはイケてる⽅がいい 9/54
  11. 11. PMP for Cacti 10/54
  12. 12. PMM 11/54
  13. 13. Mackerel 12/54
  14. 14. 話変わるけど、中国地⽅にい る ないエンジニアのそーだ いさんという⽅は凄く優秀そうな⽅だし、 13/54
  15. 15. 家族思いだし、 14/54
  16. 16. 尊敬するエンジニアの⼀⼈です。 15/54
  17. 17. 閑話休題 16/54
  18. 18. ステータスモニタリングで思うこと(again) 有意義な 情報がほしい なるべく ⼿間はかけたくない 平たく⾔うとデータソース取得メソッドは⾃分で書きたくない もっと⾔うと SHOW ENGINE INNODB STATUS を正規表現でパースしたくない - ビバ エコシステム- しなくていいなら 運⽤したくない どうせなら フロントエンドはイケてる⽅がいい 17/54
  19. 19. だがしか し 18/54
  20. 20. 気に⼊るもの がなかったら 19/54
  21. 21. 我々はどうや って戦えばい いんだろう 20/54
  22. 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. 23. SHOW ステートメント ⼀応SQL 結果セットはカラムと⾏から成るフツーのSQLと同じ結果セ ット フツーに⽣DBIでもORMでもアクセスできる- ただし SHOW ENGINE INNODB STATUS は 1⾏3カラムの結果セットで、 “Status” カラムの中にテキストで⼊ってるからパース地獄 - 細かいことを⾔うと information̲schema の仲間 22/54
  24. 24. SHOW vs i̲s / p̲s i̲s, p̲sへのアクセスは完全なSQL SHOW にも LIKE や WHERE が書けるけど、 ORDER BY, GROUP BY には対 応していない - SELECTアクセスが基本な奴らだから(︖)変にパースを要 求するものが あんまり ない たまにある- 23/54
  25. 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
  26. 26. information̲schema vs performance̲schema information̲schema SQLでアクセスする時に情報が集められる。運が悪いと刺さる performance̲schema 既に情報は蓄積されていて、SQLでアクセスする時は引っ張り出すだけ。少 しずつオーバーヘッドが載る 25/54
  27. 27. SHOW GLOBAL STATUS information̲schema.GLOBAL̲STATUS グローバルのステータスカウンターと、今⽣きている全てのthdのステータ スカウンターを ⾜し合わせて 表⽰する performance̲schema.global̲status 各thdがステータスカウンターをインクリメントする時ついでにp̲sがインク リメントされる 26/54
  28. 28. SHOW PROCESSSLIST information̲schema.PROCESSLIST 各thdを1個ずつロックしてステータスを表⽰する performance̲schema.threads 各thdがStateを変更するたびにp̲sが更新される 27/54
  29. 29. performance̲schema #とは イベントベースのプロファイラー インストゥルメントを通過するたびに performance_schema スキーマのテーブルに情報が蓄積される 機能の名前としての「パフォーマンススキーマ」、スキーマ の名前空間として「performance̲schemaスキーマ(データ ベース)」、パフォーマンススキーマの情報を格納する専⽤ の「performance̲schemaストレージエンジン」があるの がややこしい オンメモリーストレージエンジンなので永続化はしない- 記録に特化しているので参照は地味に遅い(MySQL 8.0で良くなるら しい) - i̲sだったら「刺さったか︕︖」と思うくらい待たされても、p̲sは刺 さってなくて単に重いだけの場合が多い - 28/54
  30. 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. 31. たとえばテーブルサイズ innodb_stats_on_metadata= 0 にすること︕ (5.6とそれ以 降はデフォルトで0) LIMITはお好みで。⼤概、トップ20とか30とか取って置け ば⾜りると思う i̲sだからもちろん誤差はある。リアルタイムな値じゃなく てデイリーやウィークリーで⼗分 30/54
  32. 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
  33. 33. たとえばテーブルサイズ 32/54
  34. 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
  35. 35. たとえばspin̲rounds 34/54
  36. 36. たとえばInnoDBバッファプールの内訳 information̲schema.innodb̲buffer̲page, innodb̲buffer̲page̲lruで⾒られるけれど このクエリーInnoDBバッファプールが⼤きければ⼤きいほ ど負荷⾼いので、流⾏ってるところでは常⽤には向かないと 思う sys.innodb̲buffer̲stats̲by̲schema, innodb̲buffer̲stats̲by̲table, schema̲table̲statistics̲with̲bufferあたりもこのテーブ ルに触るので注意だ 35/54
  37. 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. 38. たとえばテーブルアクセスの読み書きレイテンシー これ累計なので、累計のままストアするか差分にしてストア するかは好み Mackerelは累計値で投げてもグラフ側で差分描写にできて いいなあ 37/54
  39. 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
  40. 40. たとえばテーブルアクセスの読み書きレイテンシー 39/54
  41. 41. たとえばテーブルごとのRead/Write回数 Perlでも⼗分マカレる 40/54
  42. 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
  43. 43. たとえばクエリーダイジェストごとのrows̲examined 42/54
  44. 44. たとえば更新系のクエリーダイジェストごとの発⾏数推移 43/54
  45. 45. SQLで引ける ということは 44/54
  46. 46. Perlで(も)引 けるというこ と 45/54
  47. 47. 今使ってるヤーツ 46/54
  48. 48. 今のヘーシャのステータスモニタリング(?) メインはPMP for Cacti 深く監視するにはお⼿製スクリプト(Perl) データはそれ⽤のMySQLに格納してあるので、必要に応じてre:dash でグラフにする - ⼀周回って「これをCactiに⾷わせればいいんじゃないか」とか「パー ジするデータはrrdtoolに⼊れちゃえばいいんじゃないか」とか思って きた - ショットでモニタリングしたい時はPMM PMM ServerはDocker image- PMM Agentはrpmで⼊れる- 47/54
  49. 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. 50. 気に⼊っているところ どれも吊るしのMySQLから情報が取れる performance̲schemaはMySQL 5.6以降デフォルトでON パラメーター何もいじらなくてもそれなりに情報が取れる- innodb̲metricsをガリガリ使いたいなら innodb_monitor_enable = all だがしかしどちらも実質5.6から 49/54
  51. 51. おかげさまで +---------+-------+ | version | count | +---------+-------+ | 4.0 | 2 | | 5.0 | 38 | | 5.1 | 17 | | 5.5 | 22 | | 5.6 | 126 | | 5.7 | 106 | +---------+-------+ 50/54
  52. 52. ほら 51/54
  53. 53. それ、Perlで (も)できるで しょ 52/54
  54. 54. みんな楽しいス テータスモニタ リングライフを 53/54
  55. 55. Questions and/or Suggestions? 54/54

×