NAND Flash から InnoDB にかけての話（仮）

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
7. Copyright © GREE, Inc. All Rights Reserved. はじめに 7
8. Copyright © GREE, Inc. All Rights Reserved. • これからお話する内容は、 SSD や MySQL などについて、個人的な経 験などに基づく個人的な見解の上に述べているのであって • 所属団体や組織を代表する見解ではありません。 • さいきんの NVMe などは評価してないので、今後もこういった傾向にある かどうかはわかりませんし • QLC NAND で InnoDB 動かしたことないので、 QLC の特性について は知見がありません • SSD などについては、製造しているメーカーごとの特性などもありますの で、あくまで参考程度にしてください。 注意事項 8
9. Copyright © GREE, Inc. All Rights Reserved. NAND Flash の性能を考える上で ちょうざっくり 9
10. Copyright © GREE, Inc. All Rights Reserved. • （いまさら比べるのもアレですが） • HDD と比べ、 random I/O がとにかく速い • read が速い • write が速い SSD は何がうれしい 10
11. Copyright © GREE, Inc. All Rights Reserved. SSD は write が速い・・・？ 11
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
14. Copyright © GREE, Inc. All Rights Reserved. これらが 意味するところは 14
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
17. Copyright © GREE, Inc. All Rights Reserved. SSD の性能は一様ではない 17
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
22. Copyright © GREE, Inc. All Rights Reserved. Reserved Spaceが少ないモデル 22
23. Copyright © GREE, Inc. All Rights Reserved. Reserved Spaceが多いモデル 23
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
26. Copyright © GREE, Inc. All Rights Reserved. SSD 単体のベンチマークを、 どのように考えるか 26
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
32. Copyright © GREE, Inc. All Rights Reserved. TRIM との付き合い方 32
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
39. Copyright © GREE, Inc. All Rights Reserved. さいきんの Linux で考慮することを、 強いてあげるならば 39
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
46. Copyright © GREE, Inc. All Rights Reserved. では InnoDB でどうするか 46
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
56. Copyright © GREE, Inc. All Rights Reserved. おわり