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

  • 5,963 views
Uploaded on

2013/11/30 Chiba.pm #4

2013/11/30 Chiba.pm #4

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
5,963
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
33
Comments
0
Likes
26

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

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