MySQLチューニング

MySQL パラメーターチューニングの理屈と定石 2014/03/01 yoku0825@MyNA OSC 2014 Tokyo Spring

＼こんにちは／ ● ● ● ● とある企業のＤＢＡ ● オラクれない ● ポスグれない ● マイエスキューエるその正体は ● 嫁の夫 ● せがれの父日本 MySQL ユーザ会 (MyNA) のすべり担当 #mysql_jp でツッコミをいただけると幸い

おしながき ● ● MySQL のパラメーターとは何か根性論（理屈） ● ● ● ● 実際役に立つかどうかは置いておいて、基本的な考え方これはきっと MySQL に限らないはず調査に使うコマンドとかのりたまふりかけ（定石）

MySQL のパラメーターとは ● 基本的に「ハードウェアのリソースを使い切らないための安全弁」 ● ● ● ● ● 低すぎると性能が頭打ちされるし高すぎると不安定になったりリソースを食い合って性能を下げたり基本的には「必要なぶん + 余裕度」「必要なぶん」の最適値は環境によって違うし、見積りがとても難しい現状足りているか足りていないかは多少調べがつく

性能必要リソースリソースの競合割当リソース

根性論（理屈） ● とにかく比較するしかない ● パラメーターを { 上げ | 下げ } てみる – – ● ● 性能が上がってるならまだ足りてない性能が下がってるなら割り当てすぎてる 2 か所以上を同時に変更してはいけない目の前にあるものを直視する ● ● 速くしたいのは今目の前にあるアクセスパターンベンチマークで速くなった、誰かが上手くやったパラメーターをそのまま適用しても、目の前のものも速くなるとは限らない

根性論（理屈） ● 限界値 , 定常値を知る ● ● パラメーターをどれだけ変えても、ハードウェアの限界値を超えて性能を出すことはできない今の状況は、まだ頑張れば伸びる ( はず ) なのか、もう諦め時なのか – ● 1 年間チューニングして、 1ms 速くなりましたって訳にはいかないのも含む目的を絞る ● 性能 = Σ( 速さ , 可用性 , 安定性 , 運用性 , ..) – ● 速さ = Σ( レスポンスタイム , スループット , ..) 基本的にトレードオフ。何を捨てて、何を得るのか。

根性論（理屈） ● 継続的に改善する ● ● ● パラメーターの最適値が見つかったとしても、それは「その時点での」最適値にすぎない新しいクエリーがリリースされれば、新しい最適値が生まれるパラメーターだけにこだわらない ● ● 他にもチューニングできる箇所はたくさんあるはず概して、パラメーターいじるより SQL 変えた方が高速化には寄与することが多い

調べ方

比較する ● 一番シンプルなのは、本番機で innotop と dstat 流しながら SET GLOBAL .. ● ● 変更前後で「ほぼ同じメモリー状態に」「ほぼ同じクエリー」が「ほぼ同じ量」流れてくることが期待できるので、パラメーター変更に本当に効果があったかどうかが一番測りやすい。ユーザー企業でよかったと思う瞬間。

SET GLOBAL で変更するとき ● グローバルでしか存在しないもの ● ● 変更した瞬間からその値で処理が始まるグローバルもセッションも存在するもの ● ● ● グローバル値は基本的にセッション値の暗黙のデフォルト値セッション値が新しく作られる (= コネクションの ) タイミング以外ではグローバル値の変更は効果を及ぼさないセッション値が実効パラメーター

SET GLOBAL で変更するとき ● 反映に再起動が必要なものは ● mysqld を再起動するとメモリー状態は盛大に変わる – – 5.6 で InnoDB Buffer Pool Dump が入ったとはいえキャッシュ状態が違うと、比べた結果がアテにならなかったりもする ● ● 自分でキャッシュ状態をある程度一定に保つテクニックが必要簡単に再起動できない mysqld もある – 基本的にはこの類のパラメーターは事前に計算しておくのが必要

目の前にあるもの ● 問題が起きている箇所を特定する ● ● スロークエリーログ innotop で Time, State を観察 – ● ● SHOW FULL PROCESSLIST でもいい SHOW GLOBAL STATUS; どのパラメーターをいじるべきか考える ● EXPLAIN で、 SQL 側の問題ではないことを確認しておく – ● クソクエリーはパラメーターじゃ速くならない profile で「どのステップで問題なのか」を調べる – I/O がイケてないのに、ソートのパラメーターを変えてもダメ

どこに効くパラメーターが必要？

SHOW GLOBAL STATUS ● ● ● ● ● ● ● なんちゃら disk なんちゃらとかなんちゃら cache とか InnoDB なんちゃら pending なんちゃらとか sort なんちゃらとか thread なんちゃらとか table_open_cache なんちゃらとかどれがカウントアップされたらどのパラメーターをいじるのかはリファレンスとにらめっこ ● http://dev.mysql.com/doc/refman/5.6/en/serverstatus-variables.html

SHOW ENGINE INNODB STATUS ● ● SEMAPHORES セクション TRANSACTIONS セクション ● ● FILE I/O セクション ● ● ● たまにどこのラッチがほしくて待ってるかの細かい情報が出る Pending なんちゃら LOG セクション BUFFER POOL AND MEMORY セクション

performance_schema ● ● ● ● ● 5.6 でだいぶ取れる情報が増えたとはいえ、 performance_schema 自体の情報が少なくて今がんばってるオーバーヘッド怖いメモリーごりごり食う ps_helper と直アクセスと使い分ける感じになりそう

限界値を知る ● ベンチマークソフトが良く使われる ● ● ● ストレージの速度 fio MySQL の OLTP 的なクエリーを流しまくる sysbench, tpcc-mysql カタログスペック的なイメージ ● ● 飽くまでも参考値というか、「どう頑張ってもこれ以上は出ないだろうなー」という感じ今の状態が、ちょっと頑張れば伸びそうなのか、頑張れば伸びるだろうけど伸びは悪そうなのか、これ以上はスケールするしかないのか

定常値を知る ● グラフ化しておくとべんり ● ● ● ● ● ● Percona Monitoring Plugins for Cacti ドリルダウンして調べたい時はお手製スクリプトパラメーター変更後に効果が出たのか出なかったのかタイミングの問題で気付けないことが長いスパンの中で現れてくることもパラメーターに限らずトラブルシュート全般に役立ちます継続的な改善にも必須

Percona Monitoring Plugins for Cacti

パラメーターだけにこだわらない ● 飽くまで 1 手段に過ぎない ● ● ● ● ● ● ハードウェアを変えるパラメーターを変えるテーブル構造を変えるＳＱＬを変えるバイナリーを変える OS レイヤーのパラメーターを変える

ハードウェアリソース ● 全ての処理が無限に速くなれば処理時間も無限に 0 に近付く ● ● ● リソースの競合が始まるタイミングを決める ● ● 個々の動作の高速化あって困ることはないなくて困ることはある現状の構成でまだイケるのか、スケールどきなのかはベンチマークソフトで測るのが便利 ● 大体にして、似た様なクエリーの他のサーバーをモデルにすることも多い

性能必要リソースリソースの競合割当リソース

テーブル構造 ● 適切なインデックス ● ● ● ● インデックスは「ソート済みのデータの複製」検索には ( オプティマイザーの戸惑いを除いて ) 悪影響はなし更新には必ずオーバーヘッドになる大概の場合「要るなら作る」の一択だが、書き込みボトルネックになっているなら「マスターからは消す、スレーブには残す」とか考える – 運用的なツラみとのトレードオフ

テーブル構造 ● 適度な正規化 ● ● ● ● ● ● 基本は全力で正規化するべき非正規化した方が GROUP BY とか当然速い非正規化するとデータ量が増えたり、 1 トランザクション内で更新する箇所が増えて I/O 増えたり、不整合が発生する可能性も非正規化はダーティーハックダーティーハックであることを忘れてスタンダードになるとツラいストレージエンジン ● 基本的には InnoDB 統一がいいんですが

SQL を変える ● MySQL はあんまり難しいことできない ● ● ● ● 何とかとハサミは使いよう ● ● ● ORDER BY .. ASC, .. DESC とか相関サブクエリーとか多段で JOIN とか、テンポラリーテーブル使ったりアプリ側でマージしたり MySQL が無理せずできることだけやらせるループや関数演算はアプリ側に持たせてやると幸せになることが多い ○racle DB はなんだかんだ言ってすごい ● アレを基準にすると 3 歳児レベルだと思った方が

バイナリーを変える ● ● メジャーバージョンアップで機能が強化されてたり本家 MySQL 以外の選択肢 ● ● ● ● ● Facebook MySQL Twitter MySQL MariaDB Percona Server PostgreSQL

OS レイヤーを変える ● ● ● ● ● ● ext3 より ext4 の方が性能が良いとかマウントオプション noatime とか queue/scheduler を deadline とか noop とか numactl とか Transparent Hugepage とか概して情報量が少ないけれど

のりたまふりかけ ● カジュアルに変更できないやつ ● ● innodb_buffer_pool_size, innodb_log_file_size, innodb_log_files_in_group, innodb_flush_log_at_trx_commit, query_cache_size( を減らす ) カジュアルに変更で対応するやつ ● max_connections, thread_cache_size, table_open_cache, max_heap_table_size, tmp_table_size, read_buffer_size, read_rnd_buffer_size, sort_buffer_size, join_buffer_size, binlog_cache_size, key_buffer_size, innodb_io_capacity, innodb_io_capacity_max

innodb_buffer_pool_size ● ● InnoDB で一番性能に直結するパラメーターバッファプールは「データ , インデックスのキャッシュ」だけではなく、「最初にデータが書かれる場所」でもある ● ● INSERT, DELETE でも使うマニュアルのいわく、物理メモリーの 80% 以上割り当てろ ● ● InnoDB が使うメモリーはさらに 1 割くらいオーバーヘッドが載る ( 余裕度込みで ) データが全て収まるのが理想

机上で計算 ● データサイズ ● ● ● インデックスサイズ ● ● http://dev.mysql.com/doc/refman/5.6/en/storage -requirements.html ↑ あたりを参考にインデックスに含まれるカラムのデータサイズ + プライマリキーのサイズとはいえ大体 varchar, text 型のサイズ * キャラクターセットが支配する ● utf8 で varchar(255) を含むテーブル => 800bytes/row 弱

バッファプール確認 ● ● mysql> SELECT SUM(data_length) AS data_length, SUM(index_length) AS index_length FROM information_schema.tables WHERE engine= 'InnoDB'; +-------------+--------------+ | data_length | index_length | +-------------+--------------+ | 156237824 | 32522240 | +-------------+--------------+ 1 row in set (0.04 sec) mysql> SHOW ENGINE INNODB STATUSG .. ---------------------BUFFER POOL AND MEMORY ---------------------Total memory allocated 38425067520; in additional pool allocated 0 Dictionary memory allocated 708200 Buffer pool size 2293759 Free buffers 2281361 Database pages 9526 Old database pages 3496 ..

バッファプール確認 ● ● mysql> SHOW ENGINE INNODB STATUSG .. ---------------------BUFFER POOL AND MEMORY ---------------------.. Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000 .. mysql> SHOW GLOBAL STATUS LIKE 'innodb_buffer_%read%'; +---------------------------------------+---------------+ | Variable_name | Value | +---------------------------------------+---------------+ | Innodb_buffer_pool_read_ahead | 5691980889 | | Innodb_buffer_pool_read_ahead_evicted | 11862757 | | Innodb_buffer_pool_read_requests | 2074130774514 | | Innodb_buffer_pool_reads | 136410489 | +---------------------------------------+---------------+ 4 rows in set (0.00 sec)

innodb_log_file_size ● ● 5.6 未満では、反映に再起動のみならず ib_logfile* の再作成が必要だったログファイルの性能は innodb_log_file_size* innodb_log_files_in_group に比例する ● ● ● 個人的には innodb_log_files_in_group は 2 でいいログファイルの性能は書き込み処理に影響 5.5 未満では増やしすぎるとクラッシュリカバリーに時間がかかるらしい ● 5.5 以降なら、変更のしにくさも鑑みて予め大きめにして良いと思う

ログファイル確認 ● ● mysql> SHOW ENGINE INNODB STATUSG .. --LOG --Log sequence number 158185651300 Log flushed up to 158185651244 Last checkpoint at 158185645072 0 pending log writes, 0 pending chkp writes .. # pt-ioprofile --cell sizes --run-time 10 Tracing process ID xxxx total pread read pwrite lseek filename .. 34304 0 0 34304 0 /data/mysql/ib_logfile1 0 0 0 0 0 /data/mysql/ib_logfile0 write fsync 0 0 0 0

innodb_flush_log_at_trx_commit ● クラッシュした時に、 * 必ず * データをバックアップなり何なりから戻す気があるかどうか ● あるなら = 0 で、ついでに skip-innodbdoublewrite してもいいです – ● skip-innodb-doublewrite や innodb-flush-log-at-trxcommit!= 1 は「 { 失う | 壊れる } かも知れない」ではなくて「 { 失って | 壊れて } もまったく検知できない」とりあえず起動して試して、ダメだったら…とかいうフローにしたいなら、 = 1 で

query_cache_size ● ● ● 基本的には query_cache_type= query_cache_size= 0 で起動したい SHOW PROCESSLIST で見たときに、 "Waiting for query cache lock" が目立つなら切った方が良いオンラインで増やすのは別にいいんだけど、減らす時は Query Cache がまるっとロックされるので時間が止まる

どうせ後で変えるやつら ● read_buffer_size= read_rnd_buffer_size= 2M sort_buffer_size= join_buffer_size= 8M ● ● ● ● ● ● 基本、ここから減らすこと前提 thread_cache_size= 70 table_open_cache= 2048 max_heap_table_size= tmp_table_size= 128M binlog_cache_size= 8M max_connections= 151 ● 500 とかやると何かあった時にサーバー死ぬ

あんまり変えない奴ら ● ● ● ● ● ● ● ● binlog_format= MIXED max_binlog_size= max_relay_log_size= 256M relay_log_info_repository= TABLE relay_log_recovery= 1 skip_name_resolve tmpdir は datadir の隣辺りに置いてる slave_load_tmpdir character_set_server

MySQLチューニング

by yoku0825 on Mar 01, 2014

Statistics

Views

Actions

2 Embeds 51

Accessibility

Categories

Upload Details

Usage Rights

Report content

MySQLチューニング Presentation Transcript

https://twitter.com	50
https://kcw.kddi.ne.jp	1