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

Copyright © GREE, Inc. All Rights Reserved.
NAND Flash から
InnoDB にかけての話（仮）
Takanori Sejima

自己紹介
● わりと MySQL のひと
● 3.23.58 から使ってる
● 前職の頃、十数年前は、 MMORPG の DB の設計などもやってました
● むかしは Resource Monitoring も力入れてやってました
● 一時期、ハードウェアの評価をガッツリやってました
● 稀に Linux の TCP プロトコルスタックについて調べたりもします
● さいきんはわりと MySQL よりなのかも
2

● 時代は流れ、ハードウェアの性能特性を考えながら MySQL を自前運用
してる人は、かつてより減ってきてると思いますが
● NAND Flash の特性や、それに対して InnoDB でどう向き合っていくか
といったことについて、私が考えたり検証してたことをざっくりまとめておけ
ば、面白い人には面白いのかもと思ったので
● 本日はそういうお話をまとめてみました
● InnoDB について理解が深まれば、 IaaS で MySQL 使う上でも（たぶ
ん）有益な気がします
● AWSさんの i3 や i3en みたいに、 NVMe SSD 使えるものもありますし
本日のお話
3

● なにはともあれ、 InnoDB 使うなら InnoDB Adaptive Flushing は
知っといて損がないです
● さいきんの InnoDB Adaptive Flushing （仮）
● MySQL 5.7 以前の情報ですが、 8.0 を理解する上でも役に立つかと思います。
● MySQL について、会社の blog にもときどき書いています
● https://labs.gree.jp/blog/author/sejima/
本日のお話の補足資料・その一
4

● 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

● はじめに
● NAND Flash の性能を考える上でちょうざっくり
● SSD の性能は一様ではない
● SSD 単体のベンチマークを、どのように考えるか
● TRIM との付き合い方
● さいきんの Linux で考慮することを、強いてあげるならば
● file system に対して意識することを、強いてあげるならば
● では InnoDB でどうするか
● まとめ
Agenda
6

はじめに
7

● これからお話する内容は、 SSD や MySQL などについて、個人的な経
験などに基づく個人的な見解の上に述べているのであって
● 所属団体や組織を代表する見解ではありません。
● さいきんの NVMe などは評価してないので、今後もこういった傾向にある
かどうかはわかりませんし
● QLC NAND で InnoDB 動かしたことないので、 QLC の特性について
は知見がありません
● SSD などについては、製造しているメーカーごとの特性などもありますの
で、あくまで参考程度にしてください。
注意事項
8

NAND Flash の性能を考える上で
ちょうざっくり
9

● （いまさら比べるのもアレですが）
● HDD と比べ、 random I/O がとにかく速い
● read が速い
● write が速い
SSD は何がうれしい
10

SSD は write が速い・・・？
11

● 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

● さいきんの SSD は TiB クラスの容量が珍しくありませんが
● NAND Flash のチップ一枚あたりは、 TiB クラスの容量があるわけでは
なく、GB/sec のスループットが出るわけではありません
● NAND Flash のチップの集合はパッケージというそうですが
● SSD の内部では、そういったパッケージが複数並べられており
● 性能を稼ぐために、パッケージらが SSD 内部のコントローラ配下で、複数
のチャネルに並べられているわけです
● このあたりは Design Tradeoffs for SSD Performance で図解されています
NAND Flash のチップ一枚あたり
13

これらが
意味するところは
14

● SSD 内部には複数のチャネルがあり、それぞれに並列して
read/write/erase を発行するのであれば、 OS やアプリケーションか
ら、シングルスレッド＆ QueueDepth=1 で read や write をしたとこ
ろで、すべてのチャネルを有効活用できるかというと、なかなかたいへんな
わけです
● SSD 内部に複数あるチャネルを有効活用するには、使う側で配慮してあ
げると良い気がします。
● マルチスレッドで非同期 I/O 使うなり、 QueueDepth を増加させるなり
● そして、非同期 I/O 使ったり、 I/O の並列度を上げる仕組みは、
InnoDB 側にも存在しています
● ただ、実際に SSD 内部でどれくらいの並列度で動作しているか
monitoring できないのが、難しいところです
SSD 内部の並列度を、如何にして上げるか
15

● QueueDepth=1 がすべてにおいて悪いかというと、必ずしもそうではな
い気がします。 Queue が深いと IOPS 稼げますが、浅いほうがレイテン
シは改善します。
● すごい雑にいうと、foregound のタスクはレイテンシ速い方が嬉しいです
し、background のタスクはスループット高いほうが良いですよね？
● 例えば、SELECT して buffer pool の miss hit 起こしたとき、 SSD から読むときは
なるべく高速な方が嬉しいですよね
● write も、 redo log に書いて commit するときはレイテンシ速いと良いかもしれませ
んが、 background で dirty page を flush するときは、レイテンシそこそこでいいで
すよね
● 一長一短あります。
QueueDepth にはトレードオフもある
16

SSD の性能は一様ではない
17

● 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

● FOB や Steady State に関する話はたまに見かけるんですが
● 私の経験から言うと、性能が変化する要因は、これだけではありません。
● FOB や Steady State 以外で、注意すべき二つのポイントについて、触れ
ておきます。
ただ、それだけではない
19

● 先ほど述べたとおり、 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

● 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

Reserved Spaceが少ないモデル
22

Reserved Spaceが多いモデル
23

● write only のテストをやってるとき、いずれも IOPS がガクンと落ちるタイミ
ングありますが、 Reserved Space 多いモデルだと、しばらくすると IOPS
が戻ってきました。
● read と write が混在しているベンチマーク流してるとき、 Reserved
Space 少ないモデルだと、 IOPS が安定しにくかったりします。
● たかだか数十分、 fio をぶん回しただけで、（当時の） SSD は、このように
性能が変動したりしてました。
● もし最近の SSD でこのような変化が起きない製品があるとしたら、それは
Reserved Space が大量に確保されていて、Gabage Collection 的な処
理がそうとう高速化されていると思います。
Garbage Collection 的な（仮）の挙動
24

● fio みたいなベンチマークのように、限界までひたすら書き込み続けるって
いう使い方、 OLTP だとやらない気もしますが
● OLAP のためのデータを import するときとか、replica を追加するときと
か、ひたすら書き込み続けることはあると思います。
● ただ、 SSD は、書き込み性能をピーク時のまま維持することはできなかっ
たりします。
● また、 OLTP だったとしても、 SSD の性能はこのように変動するものだと
いうことを理解して、あるていど余力を持たせつつ InnoDB を使ったほうが
良いかなと思います。
これらを踏まえ、 MySQL 的に意識すること
25

SSD 単体のベンチマークを、
どのように考えるか
26

● 私は、かつて MLC NAND から 3D TLC NAND の世代交代の時期を経
験しました。
● その前後で、大きく性能特性が変わってました。
NAND Flash の世代で傾向が変わる
27

● 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

● 少なくとも、 innodb_page_size の単位で I/O の性能を見ておいたほ
うが良いでしょう。
● 16KB の単位でベンチマークを取ってるSSD ベンダーは、（私が知る限り）ありません。
● read と write の比率は、実際のワークロードにあわせて試しておいたほ
うが良いでしょう
● 実際のワークロードをベンチマークで再現するのはかなり大変でしょうから、比率くらいは
合わせましょう。最終的には、 replica として試しにぶら下げて評価するのが、最も無難
かと。
innodb_page_size を意識してベンチマーク
29

● IOPS だけでなく、 SSD の帯域をどれくらい有効活用できてるか見ておい
たほうが良いでしょう。
● PCI Express や SATA の帯域を、どれくらい使い切れているか、という観点で見るのが
良いと思います。 Linux の I/O scheduler が I/O を merge してくれて、スループットは高
いんだけど IOPS としてはやや低めに出ることもあります。
● ある程度まとまった時間ベンチマークを走らせて、 Garbage Collection
的な挙動が起きてるか、見ておいたほうが良いでしょう。
● ベンチマークが完走したあと、平均値を見るのではなく、実行中の推移を確認しましょう。
● また、後述しますが、ベンチマーク実行後に fstrim など叩いて確認してお
いた方が良いこともあります。
ベンチマークする際に、できれば確認したいこと
30

● かつて、 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

TRIM との付き合い方
32

● かつて私は 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

● 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

● fstrim -v で何バイト discard したかが表示されますし、 fstrim.timer
でどれくらい discard したかは、 sudo journalctl -u fstrim で確認で
きます。
● 大量に書き込んだり大量に削除したりしてると、それだけ大量に discard
される可能性があり、あまり高性能ではない SSD だと、 fstrim した瞬間
にレイテンシがかなり悪化して、MySQLでは replication が遅れたりしま
す。
● InnoDB Adaptive Flushing のチューニングをするなどして、書き込む
量を減らすよう工夫などすると、そのあたり軽減できることがあります。
大量に書き込んだり、大量に削除したりしてると
35

● SSD のベンチマークのついでに、 fstrim 実行時の性能劣化を簡単に評
価する方法があります。
● ベンチマークなどで、大量に書き込んで大量にファイル削除したあと
● ioping 叩いてる裏で fstrim --all --verbose などを実行されると良い
でしょう
● 普段は ioping 叩いてもレイテンシは数十 usec 程度なのに、 fstrim 実
行中は msec になったりします。
● 高性能な SSD だと、 fstrim しても ioping のレイテンシにあまり影響与
えないかもですが、製品によってはかなり悪化します。
fstrim 実行時の性能劣化を確認する
36

● 次のような対処をされるのがよろしいかと思います。
● （必要であれば） 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

● fstrim を叩いたときの性能への影響は、ワークロードや製品によってまる
で異なる結果となります。
● はじめに紹介した補足資料を読んでると、 TRIM を積極的に推奨してるよ
うなものもあるかもしれませんが、その一方、ファイルシステム作ってる人
は discard option にあまり前向きでなかったりします。
● 各々立場があって、使ってる製品ごとに特性も違うわけです。
● 世の中には SSD について様々な意見や見解がありますが、 TRIM 一つ
とってもそのような立場などの違いが現れます。
● いろいろと読み比べつつ、自分ではどのように捉えるか、自分の立場で考
えるのが良いと思います。
TRIM やら補足資料やらについて
38

さいきんの Linux で考慮することを、
強いてあげるならば
39

● 社内で若い人に言われて知ったんですが、さいきんの kernel だと、
iostat -x の %util がだいぶ変わってきたようです
● iostat -x %util statistics on 4.17+ kernels #187
● 私は kernel 5.x で fio などのベンチマーク試して「 io scheduler 変
わったらしいけど、性能劣化はなさそうだ。むしろ伸びしろが増えた」みたい
なのは確認してたんですが
● ピーク性能は出やすくなったけど、負荷が低いときの %util が高めに出
るケースがあったりとか
● しょうじき、このあたりは悩ましい問題ですね。今後の kernel のアップ
デート内容を見ていきたいと思います。
/proc/diskstats 周りが変わった？
40

● この方面には疎いですが
● パッと見た限り、 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

● まぁ困ったときは 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

file system に対して意識することを、
強いてあげるならば
43

● 「ext4 より XFS がいい」という話はしばしば聞きますが、 ext4 でも性能
引き出す術はあります
● 参考：
● https://twitter.com/ts4th/status/1143878056626405376
● https://twitter.com/hirose31/status/1144092107763617792
● inode をわければ、 ext4 でもスケールすることもあります。
● つまり、MySQL 的には、 table を分割、 sharding していけば、 ext4
であっても IOPS 叩き出せるんじゃないかと。
ext4 はダメなのか？
44

● WL#5655: InnoDB:Separate file to ensure atomic writes
● MySQL 8.0.20 で入ったコレですが、double write buffer のファイル
を分けることによって、 mutex の競合を避けようっていう狙いがあったそ
うです。
● （すごい雑ですが）SSD に限らず、期待した性能が出ていないときは、
mutex の競合が発生してる箇所がないか調べるのは、良いことだと思い
ますね。
InnoDB 的に似たような話として
45

では InnoDB でどうするか
46

● InnoDB Adaptive Flushing 周りの最適化はやっぱり有効なので
● 気になった方は、こちらの資料をまず読み返してみてください
● で、まずはこれを踏まえた上で
クドいかもしれませんが
47

● （私見ですが）次の意図を持って InnoDB などでチューニングします
● バックグラウンドで実行されている ERASE に配慮する
● 書き込みのスパイクをなだらかにする
● 一日あたりの書き込みの総量が減るようにチューニングする
● （必要であれば）dirty page の flush の並列度を調整してみる
● （必要であれば）purge の並列度を調整してみる
● fstrim を実行するなら、 fstrim.timer 実行時の影響が小さくなるようにする
基本的な戦略（Write Intensive な場合）
48

● （私見ですが）次の意図を持って InnoDB などでチューニングします
● 可能な限り書き込みを減らす
● Read Intensive なモデルの SSD と Write Intensive なモデルの主な違いは、
Reserved Space の多寡だったりすることもある。
● read only であれば、どちらのモデルでも性能差がないことがある
● read と write が同時に実行される場合、可能な限り、write の比率を下げてやれば、
Read Intensive なモデルの SSD でも、性能を引き出しやすくなる
● fstrim を実行するなら、 fstrim.timer 実行時の影響が小さくなるようにする
● 大量に TRIM が発生すると、性能への影響が大きいので
基本的な戦略（Read Intensive な場合）
49

● 書き込みの一時的なスパイクを抑えるのであれば、
innodb_flushing_avg_loops のチューニングがかなり効きます。
● 詳しい挙動については、以下の blog を参照してください。
● 忙しい人のための MySQL 5.7.6 DMR における InnoDB Flushing の
変更点について
書き込みのスパイクをなだらかにする
50

● 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

● 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

● 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

● buffer pool の free page が枯渇しないようにしましょう。具体的には、free
page が枯渇しがちであれば、 innodb_lru_scan_depth を調整することを
検討しましょう。
● innodb_lru_scan_depth について、詳しくは以下の資料で解説していま
す。
single page flush を避けるには
54

● SSD は性能を稼ぐため、内部的に複数のチャネルを持っています。
QueueDepth が浅い場合、複数のチャネルが活かせずに、カタログスペッ
クほど IOPS がでないこともあります。
● ただ、 QueueDepth が浅いと、レイテンシが良かったりします
● SSD の性能は一様ではありません。バックグラウンドで GC 的なことを
やってたりもします。
● SSD の性能を評価するときは、innodb_page_sizeを意識して評価しま
しょう。
● さいきんの Linux は systemd 配下で定期的に fstrim 叩いてたりするので
気をつけましょう。
● とりあえず、InnoDB Adaptive Flushing を意識して I/O 最適化しましょう。
まとめ
55

おわり

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

More Related Content

What's hot (20)

Similar to NAND Flash から InnoDB にかけての話（仮） (20)

More from Takanori Sejima (9)

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