More Related Content
Similar to NAND Flash から InnoDB にかけての話(仮) (20)
NAND Flash から InnoDB にかけての話(仮)
- 1. Copyright © GREE, Inc. All Rights Reserved.
NAND Flash から
InnoDB にかけての話(仮)
Takanori Sejima
- 2. Copyright © GREE, Inc. All Rights Reserved.
自己紹介
● わりと MySQL のひと
● 3.23.58 から使ってる
● 前職の頃、十数年前は、 MMORPG の DB の設計などもやってました
● むかしは Resource Monitoring も力入れてやってました
● 一時期、ハードウェアの評価をガッツリやってました
● 稀に Linux の TCP プロトコルスタックについて調べたりもします
● さいきんはわりと MySQL よりなのかも
2
- 3. Copyright © GREE, Inc. All Rights Reserved.
● 時代は流れ、ハードウェアの性能特性を考えながら MySQL を自前運用
してる人は、かつてより減ってきてると思いますが
● NAND Flash の特性や、それに対して InnoDB でどう向き合っていくか
といったことについて、私が考えたり検証してたことをざっくりまとめておけ
ば、面白い人には面白いのかもと思ったので
● 本日はそういうお話をまとめてみました
● InnoDB について理解が深まれば、 IaaS で MySQL 使う上でも(たぶ
ん)有益な気がします
● AWSさんの i3 や i3en みたいに、 NVMe SSD 使えるものもありますし
本日のお話
3
- 4. Copyright © GREE, Inc. All Rights Reserved.
● なにはともあれ、 InnoDB 使うなら InnoDB Adaptive Flushing は
知っといて損がないです
● さいきんの InnoDB Adaptive Flushing (仮)
● MySQL 5.7 以前の情報ですが、 8.0 を理解する上でも役に立つかと思います。
● MySQL について、会社の blog にもときどき書いています
● https://labs.gree.jp/blog/author/sejima/
本日のお話の補足資料・その一
4
- 5. Copyright © GREE, Inc. All Rights Reserved.
● SSDとかについては、このあたり読まれるとよろしいかと
● Microsoft Research の論文。オススメ
● Design Tradeoffs for SSD Performance
● Booking.com の人による詳細な記事。オススメ
● Coding for SSDs – Part 1: Introduction and Table of Contents
● そうは言っても discard やら TRIM やらは簡単な話じゃないんだぞ、という
● Issues around discard
● その他補足
● Two traps in iostat: %util and svctm
● SSD Over-Provisioning And Its Benefits
本日のお話の補足資料・その二
5
- 6. Copyright © GREE, Inc. All Rights Reserved.
● はじめに
● NAND Flash の性能を考える上でちょうざっくり
● SSD の性能は一様ではない
● SSD 単体のベンチマークを、どのように考えるか
● TRIM との付き合い方
● さいきんの Linux で考慮することを、強いてあげるならば
● file system に対して意識することを、強いてあげるならば
● では InnoDB でどうするか
● まとめ
Agenda
6
- 8. Copyright © GREE, Inc. All Rights Reserved.
● これからお話する内容は、 SSD や MySQL などについて、個人的な経
験などに基づく個人的な見解の上に述べているのであって
● 所属団体や組織を代表する見解ではありません。
● さいきんの NVMe などは評価してないので、今後もこういった傾向にある
かどうかはわかりませんし
● QLC NAND で InnoDB 動かしたことないので、 QLC の特性について
は知見がありません
● SSD などについては、製造しているメーカーごとの特性などもありますの
で、あくまで参考程度にしてください。
注意事項
8
- 10. Copyright © GREE, Inc. All Rights Reserved.
● (いまさら比べるのもアレですが)
● HDD と比べ、 random I/O がとにかく速い
● read が速い
● write が速い
SSD は何がうれしい
10
- 12. Copyright © GREE, Inc. All Rights Reserved.
● SSD が内蔵している NAND Flash は、書き込む際、上書きするのでは
なく、 ERASE でブロックを消去してから書いてます
● むかし松信さんが描かれた図 がわかりやすいと思います
● そして ERASE は桁違いに遅いです
● Design Tradeoffs for SSD Performance には、 read/write は usec
単位ですが、 ERASE は msec 単位と記されていました
● ERASE が遅いので、性能を稼ぐために、バックグラウンドで Garbage
Collection のように ERASE することが求められ
● GC を効率よくやるため、その SSD のワークロードに対して適切な量の
Reserved Space が求められます
されど、 ERASE は遅い
12
- 13. Copyright © GREE, Inc. All Rights Reserved.
● さいきん の SSD は TiB クラスの容量が珍しくありませんが
● NAND Flash のチップ一枚あたりは、 TiB クラスの容量があるわけでは
なく、GB/sec のスループットが出るわけではありません
● NAND Flash のチップの集合はパッケージというそうですが
● SSD の内部では、そういったパッケージが複数並べられており
● 性能を稼ぐために、パッケージらが SSD 内部のコントローラ配下で、複数
のチャネルに並べられているわけです
● このあたりは Design Tradeoffs for SSD Performance で図解されています
NAND Flash のチップ一枚あたり
13
- 15. Copyright © GREE, Inc. All Rights Reserved.
● SSD 内部には複数のチャネルがあり、それぞれに並列して
read/write/erase を発行するのであれば、 OS やアプリケーションか
ら、シングルスレッド & QueueDepth=1 で read や write をしたとこ
ろで、すべてのチャネルを有効活用できるかというと、なかなかたいへんな
わけです
● SSD 内部に複数あるチャネルを有効活用するには、使う側で配慮してあ
げると良い気がします。
● マルチスレッドで非同期 I/O 使うなり、 QueueDepth を増加させるなり
● そして、非同期 I/O 使ったり、 I/O の並列度を上げる仕組みは、
InnoDB 側にも存在しています
● ただ、実際に SSD 内部でどれくらいの並列度で動作しているか
monitoring できないのが、難しいところです
SSD 内部の並列度を、如何にして上げるか
15
- 16. Copyright © GREE, Inc. All Rights Reserved.
● QueueDepth=1 がすべてにおいて悪いかというと、必ずしもそうではな
い気がします。 Queue が深いと IOPS 稼げますが、浅いほうがレイテン
シは改善します。
● すごい雑にいうと、foregound のタスクはレイテンシ速い方が嬉しいです
し、background のタスクはスループット高いほうが良いですよね?
● 例えば、SELECT して buffer pool の miss hit 起こしたとき、 SSD から読むときは
なるべく高速な方が嬉しいですよね
● write も、 redo log に書いて commit するときはレイテンシ速いと良いかもしれませ
んが、 background で dirty page を flush するときは、レイテンシそこそこでいいで
すよね
● 一長一短あります。
QueueDepth にはトレードオフもある
16
- 18. Copyright © GREE, Inc. All Rights Reserved.
● SNIA の Understanding SSD Performance Using the SNIA SSS
Performance Test Specification には、次の3つの状態について記述され
ています
● Fresh-Out-of-Box (“FOB”)
● Transition
● Steady State
● 紙幅に余裕がないので詳しい解説は省きますが、雑に言うと、買ってすぐ
の SSD は性能が高めに出て、しばらく書いてると性能がある程度のところ
で落ち着くって話です。
FOB、 Transition、 Steady State
18
- 19. Copyright © GREE, Inc. All Rights Reserved.
● FOB や Steady State に関する話はたまに見かけるんですが
● 私の経験から言うと、性能が変化する要因は、これだけではありません。
● FOB や Steady State 以外で、注意すべき二つのポイントについて、触れ
ておきます。
ただ、それだけではない
19
- 20. Copyright © GREE, Inc. All Rights Reserved.
● 先ほど述べたとおり、 SSD は バックグラウンドで ERASE して、書込み可
能な領域を回収しています。 Design Tradeoffs for SSD Performance で
は、 Background cleaning にも触れられていますし、Seagate のこの記
事 でも触れられています。。
● Reserved Space が少ないモデルで、長時間書き込みを続けると、 SSD
の性能がガクッと落ちるタイミングがあります。
● おそらく、 Background cleaning が追いつかないのでしょう。
● SSD の内部のコントローラの性能や、Reserved Space の容量などによって律速されて
いるのではないかと。
● 特に、 Reserved Space が少ない、 Read Intensive なモデルを使ってる
ときは注意かなと。
Garbage Collection 的な(仮)
20
- 21. Copyright © GREE, Inc. All Rights Reserved.
● 3年くらい前の、古い記録で恐縮なんですが
● fio で SSD の容量半分くらい使うサイズのテストデータを流し込んだ後、
● read only (50分) -> write only (50分) -> (テストデータ生成) -> read:write=70:30 (50
分) -> (テストデータ生成)-> read:write=75:25 (50分)
● IOの単位は 4KB
● みたいなベンチマークを流したときの記録です
● 青の線が write で緑の線が read です
● 一枚目のグラフは、 read:write=75:25 のテストが途中で切れてますけど
ご容赦ください
Garbage Collection 的な(仮)の実例
21
- 24. Copyright © GREE, Inc. All Rights Reserved.
● write only のテストをやってるとき、いずれも IOPS がガクンと落ちるタイミ
ングありますが、 Reserved Space 多いモデルだと、しばらくすると IOPS
が戻ってきました。
● read と write が混在しているベンチマーク流してるとき、 Reserved
Space 少ないモデルだと、 IOPS が安定しにくかったりします。
● たかだか数十分、 fio をぶん回しただけで、(当時の) SSD は、このように
性能が変動したりしてました。
● もし最近の SSD でこのような変化が起きない製品があるとしたら、それは
Reserved Space が大量に確保されていて、Gabage Collection 的な処
理がそうとう高速化されていると思います。
Garbage Collection 的な(仮)の挙動
24
- 25. Copyright © GREE, Inc. All Rights Reserved.
● fio みたいなベンチマークのように、限界までひたすら書き込み続けるって
いう使い方、 OLTP だとやらない気もしますが
● OLAP のためのデータを import するときとか、replica を追加するときと
か、ひたすら書き込み続けることはあると思います。
● ただ、 SSD は、書き込み性能をピーク時のまま維持することはできなかっ
たりします。
● また、 OLTP だったとしても、 SSD の性能はこのように変動するものだと
いうことを理解して、あるていど余力を持たせつつ InnoDB を使ったほうが
良いかなと思います。
これらを踏まえ、 MySQL 的に意識すること
25
- 27. Copyright © GREE, Inc. All Rights Reserved.
● 私は、かつて MLC NAND から 3D TLC NAND の世代交代の時期を経
験しました。
● その前後で、大きく性能特性が変わってました。
NAND Flash の世代で傾向が変わる
27
- 28. Copyright © GREE, Inc. All Rights Reserved.
● NAND チップの容量や性能特性が変わって
● SSD 内部のチャネルの本数などが(おそらく)変わってます。
● このへんは非公開情報なので、推測の域を出ませんが。
● すべてにおいて、最新世代の SSD が最高性能ではありません。
● 多くの場合、 3D TLC NAND の方がベンチマークで良い結果が出ますけど
● MLC のほうが、ブロックサイズが大きい(512KB 単位など)の random I/Oで高性能
なこともありました。
● Design Tradeoffs for SSD Performance で触れられている、ganging 関連の最適化の影
響かもしれませんね
● 4KB や 16KB など、さまざまな単位で random I/O の性能評価をやっ
てみるとわかりますが、 SSD の世代によって、得意な I/O のサイズなど
異なったりします。
チップが変わる、チャネルが変わる
28
- 29. Copyright © GREE, Inc. All Rights Reserved.
● 少なくとも、 innodb_page_size の単位で I/O の性能を見ておいたほ
うが良いでしょう。
● 16KB の単位でベンチマークを取ってるSSD ベンダーは、(私が知る限り)ありません。
● read と write の比率は、実際のワークロードにあわせて試しておいたほ
うが良いでしょう
● 実際のワークロードをベンチマークで再現するのはかなり大変でしょうから、比率くらいは
合わせましょう。最終的には、 replica として試しにぶら下げて評価するのが、最も無難
かと。
innodb_page_size を意識してベンチマーク
29
- 30. Copyright © GREE, Inc. All Rights Reserved.
● IOPS だけでなく、 SSD の帯域をどれくらい有効活用できてるか見ておい
たほうが良いでしょう。
● PCI Express や SATA の帯域を、どれくらい使い切れているか、という観点で見るのが
良いと思います。 Linux の I/O scheduler が I/O を merge してくれて、スループットは高
いんだけど IOPS としてはやや低めに出ることもあります。
● ある程度まとまった時間ベンチマークを走らせて、 Garbage Collection
的な挙動が起きてるか、見ておいたほうが良いでしょう。
● ベンチマークが完走したあと、平均値を見るのではなく、実行中の推移を確認しましょう。
● また、後述しますが、ベンチマーク実行後に fstrim など叩いて確認してお
いた方が良いこともあります。
ベンチマークする際に、できれば確認したいこと
30
- 31. Copyright © GREE, Inc. All Rights Reserved.
● かつて、 16KB より 4KB の方が random I/O で高性能な SSD もあっ
た(らしい)ので、それであれば、 innodb_page_size=4K で良かったか
なと思います。
● 最近の SSD であれば、まずは 16KB の random I/O で、その SSD
の帯域をどれくらい使えているか、評価すれば良いかなと思います。
● page が多すぎると buffer pool の管理コストが上がるので、page はあ
まり小さすぎない方が良いですし
● 特に、最近はメモリたくさん積めるようになったので、buffer pool に割り当てられるメモ
リ増えましたし
● 逆に、page size が大きすぎると、結果的に無駄な I/O が増えるでしょう
innodb_page_size の最適値について補足
31
- 33. Copyright © GREE, Inc. All Rights Reserved.
● かつて私は LinuxのTRIMサポートにはあまり期待していない と言ってい
ました。
● discard option については、ファイルシステム開発者も推奨してなかっ
たりするようです。
● ただ、 Ubuntu などでは、 discard option 有効にしていなくても、
fstrim が実行されます。かつては cron で fstrim が起動してましたが、
いまや systemd 配下の fstrim.timer です。
● 私は CentOS 等使ってないですが Fedora で Enable fstrim.timer
by default とあるので、 Ubuntu 以外でも普及しているのでしょう。
● Facebook では fstrim を定期的に実行している ようです。
fstrim.timer
33
- 34. Copyright © GREE, Inc. All Rights Reserved.
● Ubuntu 18.04 LTS のデフォルトでは、 fstrim.timer は
OnCalendar=weekly で設定されているので、毎週月曜午前0時に起動し
ます。
● サービスによってはモロにピークタイムで、(SSD の使い方によっては)即
死級のダメージが入る可能性があります。
● ゲームだと午前0時なんてログインボーナスとかありがちじゃないですか・・・
● drop-in ファイルで fstrim.timer 起動時間を変更するのがおすすめです
が、 OnCalendar は書式に若干クセが有ると思うので、次の issue も参考
にしてください
● Can't override OnCalendar #3233
Ubuntu のデフォルトは、午前0時に fstrim
34
- 35. Copyright © GREE, Inc. All Rights Reserved.
● fstrim -v で何バイト discard したかが表示されますし、 fstrim.timer
でどれくらい discard したかは、 sudo journalctl -u fstrim で確認で
きます。
● 大量に書き込んだり大量に削除したりしてると、それだけ大量に discard
される可能性があり、あまり高性能ではない SSD だと、 fstrim した瞬間
にレイテンシがかなり悪化して、MySQLでは replication が遅れたりしま
す。
● InnoDB Adaptive Flushing のチューニングをするなどして、書き込む
量を減らすよう工夫などすると、そのあたり軽減できることがあります。
大量に書き込んだり、大量に削除したりしてると
35
- 36. Copyright © GREE, Inc. All Rights Reserved.
● SSD のベンチマークのついでに、 fstrim 実行時の性能劣化を簡単に評
価する方法があります。
● ベンチマークなどで、大量に書き込んで大量にファイル削除したあと
● ioping 叩いてる裏で fstrim --all --verbose などを実行されると良い
でしょう
● 普段は ioping 叩いてもレイテンシは数十 usec 程度なのに、 fstrim 実
行中は msec になったりします。
● 高性能な SSD だと、 fstrim しても ioping のレイテンシにあまり影響与
えないかもですが、製品によってはかなり悪化します。
fstrim 実行時の性能劣化を確認する
36
- 37. Copyright © GREE, Inc. All Rights Reserved.
● 次のような対処をされるのがよろしいかと思います。
● (必要であれば) fstrim.timer が実行される時間を、深夜帯などにずらしましょう
● MySQL からの書き込みを減らすよう、 InnoDB Adaptive Flushing などのチューニ
ングをしてみましょう
● innodb_flushing_avg_loops などオススメです
● (必要であれば) fstrim.timer が実行される間隔を短くします。
● 例:週に一回ではなく、一日一回にするなど
● fstrim.timer でどれくらい TRIM 実行されたかは journalctl で確認し
ましょう
● sudo journalctl -u fstrim
● SSD の評価時に試したいなら、 ioping 叩いてる裏で fstrim してみると
か
fstrim.timer との付き合い方
37
- 38. Copyright © GREE, Inc. All Rights Reserved.
● fstrim を叩いたときの性能への影響は、ワークロードや製品によってまる
で異なる結果となります。
● はじめに紹介した補足資料を読んでると、 TRIM を積極的に推奨してるよ
うなものもあるかもしれませんが、その一方、ファイルシステム作ってる人
は discard option にあまり前向きでなかったりします。
● 各々立場があって、使ってる製品ごとに特性も違うわけです。
● 世の中には SSD について様々な意見や見解がありますが、 TRIM 一つ
とってもそのような立場などの違いが現れます。
● いろいろと読み比べつつ、自分ではどのように捉えるか、自分の立場で考
えるのが良いと思います。
TRIM やら補足資料やらについて
38
- 40. Copyright © GREE, Inc. All Rights Reserved.
● 社内で若い人に言われて知ったんですが、さいきんの kernel だと、
iostat -x の %util がだいぶ変わってきたようです
● iostat -x %util statistics on 4.17+ kernels #187
● 私は kernel 5.x で fio などのベンチマーク試して「 io scheduler 変
わったらしいけど、性能劣化はなさそうだ。むしろ伸びしろが増えた」みたい
なのは確認してたんですが
● ピーク性能は出やすくなったけど、負荷が低いときの %util が高めに出
るケースがあったりとか
● しょうじき、このあたりは悩ましい問題ですね。今後の kernel の アップ
デート内容を見ていきたいと思います。
/proc/diskstats 周りが変わった?
40
- 41. Copyright © GREE, Inc. All Rights Reserved.
● この方面には疎いですが
● パッと見た限り、 multi-queue 対応は力強く進められており
● Improvements in the block layer
● Multiqueue block layer
● Add support for multiple queue maps
● Ubuntu でも Non-multiqueue は deprecated に なってきてますね
● こういう過渡期は、 resource monitoring などで課題など発生しやすいで
すが
● SSD の内部構造を考えると、そりゃ Non-multiqueue だとやってられない
よなぁって、受け入れて行くしかない気もしますねぇ
ここ数年の block layer の動向
41
- 42. Copyright © GREE, Inc. All Rights Reserved.
● まぁ困ったときは SHOW ENGINE INNODB STATUS ですね
● FILE I/O セクションに、”Pending normal aio reads” や ”aio
writes” などありますので、非同期 I/O がどれくらい溜まってるかはここ
で確認できます。 LOG セクションにも pending log flushes などありま
す。
● また、 performance schema であれば、
table_io_waits_summary_by_index_usage や
table_io_waits_summary_by_table など も参考にできそうです。
InnoDB 的に I/O が重いか見るには
42
- 43. Copyright © GREE, Inc. All Rights Reserved.
file system に対して意識することを、
強いてあげるならば
43
- 44. Copyright © GREE, Inc. All Rights Reserved.
● 「ext4 より XFS がいい」という話はしばしば聞きますが、 ext4 でも性能
引き出す術はあります
● 参考:
● https://twitter.com/ts4th/status/1143878056626405376
● https://twitter.com/hirose31/status/1144092107763617792
● inode をわければ、 ext4 でもスケールすることもあります。
● つまり、MySQL 的には、 table を分割、 sharding していけば、 ext4
であっても IOPS 叩き出せるんじゃないかと。
ext4 はダメなのか?
44
- 45. Copyright © GREE, Inc. All Rights Reserved.
● WL#5655: InnoDB:Separate file to ensure atomic writes
● MySQL 8.0.20 で入ったコレですが、double write buffer のファイル
を分けることによって、 mutex の競合を避けようっていう狙いがあったそ
うです。
● (すごい雑ですが)SSD に限らず、期待した性能が出ていないときは、
mutex の競合が発生してる箇所がないか調べるのは、良いことだと思い
ますね。
InnoDB 的に似たような話として
45
- 47. Copyright © GREE, Inc. All Rights Reserved.
● InnoDB Adaptive Flushing 周りの最適化はやっぱり有効なので
● 気になった方は、こちらの資料をまず読み返してみてください
● さいきんの InnoDB Adaptive Flushing (仮)
● で、まずはこれを踏まえた上で
クドいかもしれませんが
47
- 48. Copyright © GREE, Inc. All Rights Reserved.
● (私見ですが)次の意図を持って InnoDB などでチューニングします
● バックグラウンドで実行されている ERASE に配慮する
● 書き込みのスパイクをなだらかにする
● 一日あたりの書き込みの総量が減るようにチューニングする
● (必要であれば)dirty page の flush の並列度を調整してみる
● (必要であれば)purge の並列度を調整してみる
● fstrim を実行するなら、 fstrim.timer 実行時の影響が小さくなるようにする
基本的な戦略(Write Intensive な場合)
48
- 49. Copyright © GREE, Inc. All Rights Reserved.
● (私見ですが)次の意図を持って InnoDB などでチューニングします
● 可能な限り書き込みを減らす
● Read Intensive なモデルの SSD と Write Intensive なモデルの主な違いは、
Reserved Space の多寡だったりすることもある。
● read only であれば、どちらのモデルでも性能差がないことがある
● read と write が同時に実行される場合、可能な限り、write の比率を下げてやれば、
Read Intensive なモデルの SSD でも、性能を引き出しやすくなる
● fstrim を実行するなら、 fstrim.timer 実行時の影響が小さくなるようにする
● 大量に TRIM が発生すると、性能への影響が大きいので
基本的な戦略(Read Intensive な場合)
49
- 50. Copyright © GREE, Inc. All Rights Reserved.
● 書き込みの一時的なスパイクを抑えるのであれば、
innodb_flushing_avg_loops のチューニングがかなり効きます。
● 詳しい挙動については、以下の blog を参照してください。
● 忙しい人のための MySQL 5.7.6 DMR における InnoDB Flushing の
変更点について
書き込みのスパイクをなだらかにする
50
- 51. Copyright © GREE, Inc. All Rights Reserved.
● SSD 内部に複数のチャネルがあるなら、複数のスレッドから非同期 I/O
で書いた方が良い気がします。
● innodb_write_io_threads で調整すればよろしいかと。基本的に、私は
CPUのコア数程度にしています。
● write intensive なワークロードであれば、 innodb_page_cleaners や
innodb_buffer_pool_instances を調整することで、 dirty page の flush
の並列度を上げられる可能性があります。
● ドキュメントにもありますが、page cleaner の数が buffer pool instance の数を超える
と、 buffer pool instance の数で丸められるので、必要に応じてbuffer pool instance の
数も見直してください。
write の並列度を上げる
51
- 52. Copyright © GREE, Inc. All Rights Reserved.
● innodb_read_io_threads というパラメータはありますけど、 read の性能
の改善は、実は難しい問題ではないかと思います。
● 例えば OLTP で SELECT が飛んできた場合、 foreground で低いレイテ
ンシで高速に処理してほしいわけです。buffer pool の miss hit が発生し
て多数の page を SSD から読む必要がある場合、 I/O 以前に、 SQL や
スキーマを改善した方が良い気もします。ちまちま miss hit が発生すると
いうワークロードなら、大量のスレッドが複数のキューを使って非同期 I/O
でスループット稼ぐ、って状況でもないわけです。
● innodb_read_io_threads を増やすことは悪いことではありませんが、「
write を減らした結果として、 read のレイテンシが改善する」というのが、
着実かなと思います。
read のための最適化
52
- 53. Copyright © GREE, Inc. All Rights Reserved.
● Design Tradeoffs for SSD Performance の 3.3 Parallelism and
Interconnect Density から引用しますと
● Ganging.
● A gang of flash packages can be utilized in synchrony to optimize a multi-page request.
Doing so can allow multiple packages to be used in parallel without the complexity of
multiple queues. However, if only one queue of requests flows to such a gang, elements
will lie idle when requests don’t span all of them
● 雑に言うと、連続した領域をまとめてアクセスすれば、 SSD 内部では複数
のチップに並列してアクセスできて最適化できるんですが
● InnoDB で 16KB だけの single page flush とかは、いかにも相性が悪い
わけですね。
● まぁ書き込みであれば、SSD 内部で DRAM のキャッシュ等持っていて、ある程度は最
適化できそうですが
SSD 内部の Ganging について補足
53
- 54. Copyright © GREE, Inc. All Rights Reserved.
● buffer pool の free page が枯渇しないようにしましょう。具体的には、free
page が枯渇しがちであれば、 innodb_lru_scan_depth を調整することを
検討しましょう。
● innodb_lru_scan_depth について、詳しくは以下の資料で解説していま
す。
● さいきんの InnoDB Adaptive Flushing (仮)
single page flush を避けるには
54
- 55. Copyright © GREE, Inc. All Rights Reserved.
● SSD は性能を稼ぐため、内部的に複数のチャネルを持っています。
QueueDepth が浅い場合、複数のチャネルが活かせずに、カタログスペッ
クほど IOPS がでないこともあります。
● ただ、 QueueDepth が浅いと、レイテンシが良かったりします
● SSD の性能は一様ではありません。バックグラウンドで GC 的なことを
やってたりもします。
● SSD の性能を評価するときは、innodb_page_sizeを意識して評価しま
しょう。
● さいきんの Linux は systemd 配下で定期的に fstrim 叩いてたりするので
気をつけましょう。
● とりあえず、InnoDB Adaptive Flushing を意識して I/O 最適化しましょう。
まとめ
55