Your SlideShare is downloading. ×
0
そろそろ基本に立ち戻って
InnoDB の話をします
か?

2013/11/30
yoku0825
Chiba.pm #4.1
Hi, All! I'm very sorry.
Today, I don't talk about Percona
たいへんもうしわけありませんが、
きょうは Per
Hi, All! I'm very sorry.
Today, I don't talk about Percona
たいへんもうしわけありませんが、
きょうは Percona のはなしを
Hi, All! I'm very sorry.
Today, I don't talk about Percona
たいへんもうしわけありませんが、
きょうは Percona のはなしをしません
Σ (゚ д ゚ lll ) えっ
今日は MySQL の話をします

\安定の Chiba.db /
みなさん、 InnoDB 使ってますか?
What is most important parameter
for InnoDB?
innodb_buffer_pool_size
Why?
What's InnoDB Buffer Pool?
InnoDB テーブルの
データとインデックスの
キャッシュ領域?
間違いじゃないけど、
それだけだとこれの説明がつかなくなる
mysql> SHOW CREATE TABLE t1G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE...
更新も速くなる
ということは、ライトキャッシュも兼ねてる?
今度はこれの説明がつかない
【 innodb_buffer_pool_size= 4G 】
mysql> DROP TABLE t1;
Query OK, 0 rows affected (2.20 sec)
【 innodb_buffer_pool_size= 32M ...
うわテストケース微妙すぎた。。
トラフィックがあってバッファプールが数十 GB になると
バージョンにもよるけど目に見えて違います
( 最近のはだいぶマシ )
なんで?
俺は
` バッファプールこそが
データ原本だから '
と説明することにしてる
SELECT のとき
●
●
●

バッファプール見る
あればそれを使う
なければテーブルスペースファイルを読んで
バッファプールに載せる
INSERT, UPDATE, DELETE のとき
●

バッファプールに書く
●

●

●

バッファプールに空きがなければ、古いページを押
し出してから書く
DELETE でさえも、書く

その後、ログファイルに書く
●

●

●

...
DROP のとき
●

●

そのテーブルの全てのページをバッファプール
から追い出す
その後、ログファイルに書いたりテーブルス
ペースファイルが削除される
常に最新の情報はバッファプールと
ログファイルに書き込まれる
バッファプールが足りないと
しょっちゅうストレージアクセス
まずは、これを足りさせること
RDS とかで Memory か IOPS かって思ったら
まずは Memory に突っ込んだ方が良い
次にログファイル
innodb_log_file_size
×
innodb_log_files_in_group
基本的にログファイルの性能はこの値に依存する
64M* 3 と 96M* 2 はほぼいっしょ
5.6 未満だと、ログファイルサイズを変える ,
ログファイルの数を減らすのにちょっと手間
ファイルを増やすのは再起動だけで OK
1 つでも壊れたらアウトなので、
個人的には 2 つを推奨
ログファイルが詰まると
全ての COMMIMT が詰まる
innodb_flush_log_at_trx
毎回は fsync せず write だけで終わらせるので
ログファイルの詰まりが減る
ただし fsync していないので
Durability を犠牲にしているのを忘れずに
innodb_file_format
* 個別テーブルスペースファイルの *
ファイルフォーマット
共有テーブルスペースは関係ない
Barracuda 一択で良いが、
それだけで性能は変わらない
innodb_io_capacity
innodb_*_io_threads
SSD とか RAID とか、
IOPS が高いなら上げる
HDD 1 玉なら触らない方が無難
他にも色々
真面目に調べ始めると奥が深くて楽しい
Chiba.pm の m は MySQL の m
楽しみましょう :)
ご清聴ありがとうございました
Upcoming SlideShare
Loading in...5
×

基本に戻ってInnoDBの話をします

7,403

Published on

2013/11/30 Chiba.pm #4

Published in: Technology

Transcript of "基本に戻ってInnoDBの話をします"

  1. 1. そろそろ基本に立ち戻って InnoDB の話をします か? 2013/11/30 yoku0825 Chiba.pm #4.1
  2. 2. Hi, All! I'm very sorry. Today, I don't talk about Percona たいへんもうしわけありませんが、 きょうは Per
  3. 3. Hi, All! I'm very sorry. Today, I don't talk about Percona たいへんもうしわけありませんが、 きょうは Percona のはなしを
  4. 4. Hi, All! I'm very sorry. Today, I don't talk about Percona たいへんもうしわけありませんが、 きょうは Percona のはなしをしません
  5. 5. Σ (゚ д ゚ lll ) えっ
  6. 6. 今日は MySQL の話をします \安定の Chiba.db /
  7. 7. みなさん、 InnoDB 使ってますか?
  8. 8. What is most important parameter for InnoDB?
  9. 9. innodb_buffer_pool_size
  10. 10. Why?
  11. 11. What's InnoDB Buffer Pool?
  12. 12. InnoDB テーブルの データとインデックスの キャッシュ領域?
  13. 13. 間違いじゃないけど、 それだけだとこれの説明がつかなくなる
  14. 14. mysql> SHOW CREATE TABLE t1G *************************** 1. row *************************** Table: t1 Create Table: CREATE TABLE `t1` ( `num` bigint(20) unsigned NOT NULL AUTO_INCREMENT, `val` varchar(32) DEFAULT NULL, UNIQUE KEY `num` (`num`), KEY `val` (`val`) ) ENGINE=InnoDB AUTO_INCREMENT=100000001 DEFAULT CHARSET=utf8mb4 1 row in set (0.03 sec) 【 innodb_buffer_pool_size= 4G 】 $ time bin/mysql -uroot d1 < ~/dump.sql real user sys 344m4.664s 1m32.631s 0m5.872s 【 innodb_buffer_pool_size= 32M 】 $ time bin/mysql -uroot d1 < ~/dump.sql real user sys 1222m16.982s 1m47.038s 0m6.243s
  15. 15. 更新も速くなる ということは、ライトキャッシュも兼ねてる?
  16. 16. 今度はこれの説明がつかない
  17. 17. 【 innodb_buffer_pool_size= 4G 】 mysql> DROP TABLE t1; Query OK, 0 rows affected (2.20 sec) 【 innodb_buffer_pool_size= 32M 】 mysql> DROP TABLE t1; Query OK, 0 rows affected (1.86 sec)
  18. 18. うわテストケース微妙すぎた。。 トラフィックがあってバッファプールが数十 GB になると バージョンにもよるけど目に見えて違います ( 最近のはだいぶマシ )
  19. 19. なんで?
  20. 20. 俺は ` バッファプールこそが データ原本だから ' と説明することにしてる
  21. 21. SELECT のとき ● ● ● バッファプール見る あればそれを使う なければテーブルスペースファイルを読んで バッファプールに載せる
  22. 22. INSERT, UPDATE, DELETE のとき ● バッファプールに書く ● ● ● バッファプールに空きがなければ、古いページを押 し出してから書く DELETE でさえも、書く その後、ログファイルに書く ● ● ● 非同期でログファイルを読んでテーブルスペース ファイルに書く テーブルスペースファイル + ログファイルで初め て完全なデータ バッファプール上にあってテーブルスペースファイ ルにないデータ ( ダーティページ ) が一定割合を超 えると強制チェックポイント
  23. 23. DROP のとき ● ● そのテーブルの全てのページをバッファプール から追い出す その後、ログファイルに書いたりテーブルス ペースファイルが削除される
  24. 24. 常に最新の情報はバッファプールと ログファイルに書き込まれる
  25. 25. バッファプールが足りないと しょっちゅうストレージアクセス
  26. 26. まずは、これを足りさせること RDS とかで Memory か IOPS かって思ったら まずは Memory に突っ込んだ方が良い
  27. 27. 次にログファイル
  28. 28. innodb_log_file_size × innodb_log_files_in_group
  29. 29. 基本的にログファイルの性能はこの値に依存する 64M* 3 と 96M* 2 はほぼいっしょ
  30. 30. 5.6 未満だと、ログファイルサイズを変える , ログファイルの数を減らすのにちょっと手間 ファイルを増やすのは再起動だけで OK
  31. 31. 1 つでも壊れたらアウトなので、 個人的には 2 つを推奨
  32. 32. ログファイルが詰まると 全ての COMMIMT が詰まる
  33. 33. innodb_flush_log_at_trx
  34. 34. 毎回は fsync せず write だけで終わらせるので ログファイルの詰まりが減る
  35. 35. ただし fsync していないので Durability を犠牲にしているのを忘れずに
  36. 36. innodb_file_format
  37. 37. * 個別テーブルスペースファイルの * ファイルフォーマット 共有テーブルスペースは関係ない
  38. 38. Barracuda 一択で良いが、 それだけで性能は変わらない
  39. 39. innodb_io_capacity innodb_*_io_threads
  40. 40. SSD とか RAID とか、 IOPS が高いなら上げる HDD 1 玉なら触らない方が無難
  41. 41. 他にも色々
  42. 42. 真面目に調べ始めると奥が深くて楽しい
  43. 43. Chiba.pm の m は MySQL の m
  44. 44. 楽しみましょう :)
  45. 45. ご清聴ありがとうございました
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×