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.

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

12,128 views

Published on

2013/11/30 Chiba.pm #4

Published in: Technology

基本に戻って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. ご清聴ありがとうございました

×