57463
AP サーバーに同居させる形で MySQL を動かしている場合、物理メモリの80%などをメモリ上にバッファ確保する、といった使い方はあまり好ましくないです。

むしろ、なるべく最小限で動かして、利用可能ならばファイルキャッシュを活用してくれた方が、サーバー管理する側からすれば嬉しくなります。

### 質問

  * MySQL で InnoDB を利用している場合に、 MySQL はどれだけ OS のファイルキャッシュを有効活用できますか？ 
    * より具体的に言うと、`innodb_buffer_pool_size` を小さく絞っているが、メモリは十分に大きい場合、その中で `innodb_buffer_pool_size` を十分大きくした場合と比べて、パフォーマンスはどのように変化しますか？

### 想定環境

  * MySQL は linux で動作させる想定です。
CC BY-SA 4.0
2019-03-22T05:47:02.333
53648
2019-08-19T15:55:09.380
754
question
mysql
MySQL の InnoDB はファイルキャッシュを有効活用できますか？
`innodb_buffer_pool_size`は物理メモリの80%、などと言われるのは、OSのキャッシュよりもRDBMSのキャッシュとして使った方が遙かに効率がよいからです。MySQLに限らず、RDBMSに共通した話です。

物理メモリの80%というのはリソースを独占できる場合の目安程度の話で、リソースを独占できる場合でも物理メモリが1GBなのか128GBなのかでも話が変わりますし、リソースを共有する他のプロセスがあるのであればそれぞれの要求量を踏まえて、MySQLに割り当てる適切な容量を決める必要があります。
CC BY-SA 4.0
2019-03-22T13:05:08.027
53657
2019-03-22T13:05:08.027
5793
53648
answer
<https://sh2.hatenablog.jp/entry/20101205>

^ 記事は少し古いですが、上記のページが、この質問に対しての参考になると思いました。内容は、 innodb_flush_method を O_DIRECT
にすることで、パフォーマンスがどのように変化していくか、を述べています。

上記のページなどを読んで自分が理解したことをまとめると:

  * MySQL の innodb_flush_method は、デフォルトでは fsync であり、これは OS キャッシュが効くような設定になっている。一方、 O_DIRECT を利用すると、 Unix の direct IO 機能を用いて、データファイル (InnoDB データ) の読み書きができるようになる。この場合、 OS のキャッシュ機構がまるまる迂回される。
  * データのすべてが innodb_buffer_pool に乗らない場合、 fsync の方がパフォーマンスが向上する。これは、 OS キャッシュが利用できているから。
  * すべてのデータが OS キャッシュに乗っていたとしても、 innodb_buffer_pool を 8MB など小さくしていくと、パフォーマンスは劣化する。 
    * これは、 MySQL がデータを読み込む際にまずファイルの内容を buffer_pool にコピーするが、OS にキャッシュされていたとしても、そのコピーのオーバーヘッドが発生しているのではと個人的には推察している。

結論としては、 OS キャッシュはそれなりにパフォーマンスに寄与している。ただ、 innodb
のバッファプールに乗っけられるならば、乗っけた方がパフォーマンスはずっと高い。メモリが許すならば、バッファプールは取れるだけ取った方がよい。
CC BY-SA 4.0
2019-08-19T15:55:09.380
57463
2019-08-19T15:55:09.380
754
53648
answer