Download as PDF, PPTX
Recommended
![[D14] MySQL 5.6時代のパフォーマンスチューニング *db tech showcase 2013 Tokyo](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2f20131110tuningonmysql5-131117180858-phpapp02-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
![[data analytics showcase] B12: サーバー1,000台を監視するということ by 株式会社インサイトテクノロジー 小幡 一郎](/image.pl?url=https%3a%2f%2fcdn.slidesharecdn.com%2fss_thumbnails%2fzwxv3e5eq2onvtifzkda-signature-1379033641429794afbc9d6c48d9c7cc5945545725d7bf5772715883640ebcaa-poli-161011071522-thumbnail.jpg%3fwidth%3d640%26amp%3bheight%3d640%26amp%3bfit%3dbounds&f=jpg&w=240)
MySQLステータスモニタリング
- 1.
- 2.
- 3.
- 4.
- 5.
- 6.
- 7.＼こんに千葉／ (c)hokke̲mirinyoku0825オラクれない-ポスグれない-マイエスキューエる-⽣息域Twitter: @yoku0825-Blog:⽇々の覚書-MyNA ML: ⽇本MySQLユーザ会-MySQL Casual: Slack-6/54
- 8.
- 9.
- 10.ステータスモニタリングで思うこと有意義な 情報がほしいなるべく ⼿間はかけたくない平たく⾔うとデータソース取得メソッドは⾃分で書きたくないもっと⾔うとSHOW ENGINE INNODB STATUS を正規表現でパースしたくない-ビバ エコシステム-しなくていいなら 運⽤したくないどうせなら フロントエンドはイケてる⽅がいい9/54
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.ステータスモニタリングで思うこと(again)有意義な 情報がほしいなるべく ⼿間はかけたくない平たく⾔うとデータソース取得メソッドは⾃分で書きたくないもっと⾔うとSHOW ENGINE INNODB STATUS を正規表現でパースしたくない-ビバ エコシステム-しなくていいなら 運⽤したくないどうせなら フロントエンドはイケてる⽅がいい17/54
- 19.
- 20.
- 21.
- 22.MySQLのステータスはどこで⾒る︖SHOW ステートメント派SHOW GLOBALSTATUS-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でもアクセスできる-ただし SHOWENGINE INNODB STATUS は 1⾏3カラムの結果セットで、“Status” カラムの中にテキストで⼊ってるからパース地獄-細かいことを⾔うと information̲schema の仲間22/54
- 24.SHOW vs i̲s/ p̲si̲s, p̲sへのアクセスは完全なSQLSHOW にも LIKE や WHERE が書けるけど、 ORDER BY, GROUP BY には対応していない-SELECTアクセスが基本な奴らだから（︖）変にパースを要求するものが あんまり ないたまにある-23/54
- 25.SHOW vs i̲s/ p̲sSHOW GLOBAL STATUSinformation̲schema.GLOBAL̲STATUS(*),performance̲schema.global̲statusSHOW PROCESSLISTinformation̲schema.PROCESSLIST, performance̲schema.threadsSHOW ENGINE INNODB STATUSinformation̲schema.INNODB̲METRICSSHOW SLAVE STATUSperformance̲schema.replication̲connection̲configuration,replication̲applier̲status̲by̲coordinator, ..SHOW TABLE STATUSinformation̲schema.TABLES24/54
- 26.
- 27.SHOW GLOBAL STATUSinformation̲schema.GLOBAL̲STATUSグローバルのステータスカウンターと、今⽣きている全てのthdのステータスカウンターを⾜し合わせて 表⽰するperformance̲schema.global̲status各thdがステータスカウンターをインクリメントする時ついでにp̲sがインクリメントされる26/54
- 28.
- 29.performance̲schema #とはイベントベースのプロファイラーインストゥルメントを通過するたびに performance_schemaスキーマのテーブルに情報が蓄積される機能の名前としての「パフォーマンススキーマ」、スキーマの名前空間として「performance̲schemaスキーマ(データベース)」、パフォーマンススキーマの情報を格納する専⽤の「performance̲schemaストレージエンジン」があるのがややこしいオンメモリーストレージエンジンなので永続化はしない-記録に特化しているので参照は地味に遅い（MySQL8.0で良くなるらしい）-i̲sだったら「刺さったか︕︖」と思うくらい待たされても、p̲sは刺さってなくて単に重いだけの場合が多い-28/54
- 30.information̲schema vs performance̲schemai̲sはMySQL5.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.
- 34.たとえばspin̲roundsmysql> 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.
- 36.
- 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.
- 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.
- 41.
- 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.
- 44.
- 45.
- 46.
- 47.
- 48.
- 49.それぞれに思うことPMP for Cactiフロントエンドとデータソースメソッドが両⼊りなので⼿間のかからなさと網羅率はいい。拡張が⾯倒お⼿製Perlフロントエンドを別に⽤意しなければいけないのがちょっと⾯倒。おとなしくre:dashを真⾯目に運⽤すればいいのかも知れないanemoeat erステータス監視じゃないけどスローログを⾷って可視化するヤーツPMMワンショットで使う分には最⾼。容量効率とPMM Serverがブラックボックス過ぎるのがネック余談だけどお⼿製Perlの記録⽤MySQLは8.0にしたくて、8.0にして窓関数使えれば⾃分で差を取らなくてもSQL（re:dash側）だけで捗りそう48/54
- 50.
- 51.おかげさまで+---------+-------+| version |count |+---------+-------+| 4.0 | 2 || 5.0 | 38 || 5.1 | 17 || 5.5 | 22 || 5.6 | 126 || 5.7 | 106 |+---------+-------+50/54
- 52.
- 53.
- 54.
- 55.