2017/07/14

1. MySQLステータスモニタリング
〜それ、Perlで(も)できるよ〜
2017/07/14
yoku0825
吉祥寺.pm 11

2. Chiba.pmの
⽅から来まし
た
1/54

3. Chiba.pm
の “m” は
2/54

4. MySQL
の”M” :)
3/54

5. ※諸説あ
ります
4/54

6. Ichikawa.pm
まだ⾏ってなく
てごめんなさい
5/54

7. ＼こんに千葉／ (c)hokke̲mirin
yoku0825
オラクれない-
ポスグれない-
マイエスキューエる-
⽣息域
Twitter: @yoku0825-
Blog: ⽇々の覚書-
MyNA ML: ⽇本MySQLユーザ会-
MySQL Casual: Slack-
6/54

8. MySQLステー
タスモニタリ
ング #とは
7/54

9. MySQLステータスモニタリング #とは
ZabbixとかCloudWatch的な⾔い回しで “メトリクス監視”
と呼んでるやつのつもり
俺はCactiスキー（単に他のを知らないとも）
おや、そういえば今⽇はMackerelの中の⼈が…︖
8/54

10. ステータスモニタリングで思うこと
有意義な 情報がほしい
なるべく ⼿間はかけたくない
平たく⾔うとデータソース取得メソッドは⾃分で書きたくない
もっと⾔うと SHOW ENGINE INNODB STATUS を正規表現でパースしたくない
-
ビバ エコシステム-
しなくていいなら 運⽤したくない
どうせなら フロントエンドはイケてる⽅がいい
9/54

11. PMP for Cacti
10/54

12. PMM
11/54

13. Mackerel
12/54

14. 話変わるけど、中国地⽅にい る ないエンジニアのそーだ
いさんという⽅は凄く優秀そうな⽅だし、
13/54

15. 家族思いだし、
14/54

16. 尊敬するエンジニアの⼀⼈です。
15/54

17. 閑話休題
16/54

18. ステータスモニタリングで思うこと(again)
有意義な 情報がほしい
なるべく ⼿間はかけたくない
平たく⾔うとデータソース取得メソッドは⾃分で書きたくない
もっと⾔うと SHOW ENGINE INNODB STATUS を正規表現でパースしたくない
-
ビバ エコシステム-
しなくていいなら 運⽤したくない
どうせなら フロントエンドはイケてる⽅がいい
17/54

19. だがしか
し
18/54

20. 気に⼊るもの
がなかったら
19/54

21. 我々はどうや
って戦えばい
いんだろう
20/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

26. information̲schema vs performance̲schema
information̲schema
SQLでアクセスする時に情報が集められる。運が悪いと刺さる
performance̲schema
既に情報は蓄積されていて、SQLでアクセスする時は引っ張り出すだけ。少
しずつオーバーヘッドが載る
25/54

27. SHOW GLOBAL STATUS
information̲schema.GLOBAL̲STATUS
グローバルのステータスカウンターと、今⽣きている全てのthdのステータ
スカウンターを ⾜し合わせて 表⽰する
performance̲schema.global̲status
各thdがステータスカウンターをインクリメントする時ついでにp̲sがインク
リメントされる
26/54

28. SHOW PROCESSSLIST
information̲schema.PROCESSLIST
各thdを1個ずつロックしてステータスを表⽰する
performance̲schema.threads
各thdがStateを変更するたびにp̲sが更新される
27/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

33. たとえばテーブルサイズ
32/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

35. たとえばspin̲rounds
34/54

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. たとえば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

40. たとえばテーブルアクセスの読み書きレイテンシー
39/54

41. たとえばテーブルごとのRead/Write回数
Perlでも⼗分マカレる
40/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

43. たとえばクエリーダイジェストごとのrows̲examined
42/54

44. たとえば更新系のクエリーダイジェストごとの発⾏数推移
43/54

45. SQLで引ける
ということは
44/54

46. Perlで(も)引
けるというこ
と
45/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

53. それ、Perlで
(も)できるで
しょ
52/54

54. みんな楽しいス
テータスモニタ
リングライフを
53/54

55. Questions
and/or
Suggestions?
54/54