omake_20190202.pdf

第26回 中国地方DB勉強会 in 岡山 （2019.2.2）枠が空いてればLTするかも？→枠が埋まったのでたぶんやりません。

Transcript

1. Aurora PostgreSQLの共有バッファ容量ってなんで 全メモリ容量の75%なの︖ （第26回 中国地⽅DB勉強会 in 岡⼭ 2019.02.02） hmatsu47（松久 裕保）
2. 今回のネタ 12/12 に JAWS-UG 名古屋⽀部で話した内容の続きです 12/12 のおさらいは次のページから…
3. おさらい１︓とある事情で PostgreSQL Advent Calendar 2018 になにか書くことに 犯⼈依頼⼈はこの⼈↓ 右⼿に持ってるのはしゃもじです 名古屋の⼈は反応がなかった（そーだいさん知名度…）
4. おさらい２︓仕⽅がないので書いた https://qiita.com/hmatsu47/items/16b8d3e1eaff9e5a6247 https://qiita.com/hmatsu47/items/7adbe764696b85c637a2
5. おさらい３︓検証内容と結果 検証内容︓ Aurora PostgreSQL 互換版では、フェイルオーバーしたと きに共有バッファと OS のディスクキャッシュは両⽅とも ⽣きのこるの︖ 結果 共有バッファはフェイルオーバーしても⽣きのこる そもそも OS レベルではディスクキャッシュしない 共有バッファのデフォルト容量は全メモリ容量の 75% PostgreSQL のセオリー（通常 25% まで）とは違う…
6. パラメータグループの shared_buffers の初期値 RDS {DBInstanceClassMemory/32768} Aurora {DBInstanceClassMemory/10922} 3 倍違う
7. ここからがこのネタの本題 共有バッファを 75% まで増やしても⼤丈夫なの︖ 遅くならないの︖
8. 資料を探してみた 「そのものズバリ」は⾒つからなかった PostgreSQL の資料はあるんだけど、Aurora が… あるっちゃあるけど（↓の P.29 〜 30） https://www.slideshare.net/AmazonWebServices/deep- dive-on-the-amazon-aurora-postgresqlcompatible- edition-dat402-reinvent-2017 12/13 の re:Invent 2018 ダイジェスト（⼤阪）でも質問でき ず…
9. 資料を読んで⾃分で考えてみた（1/2） そもそも「25% まで」の主な理由は 2 つ OS のディスクキャッシュとの⼆重管理が無駄 かといって MySQL の innodb_flush_method=O_DIRECT のような仕組みがない 容量を⼤きくするとチェックポイントの間隔を⻑くでき るかわりに、ダーティーページフラッシュの負荷が集中 する 最近は動的なチェックポイント処理もするけれど…
10. 資料を読んで⾃分で考えてみた（2/2） Aurora では 2 つとも実⾏しない データは直接ストレージノードと Reader に送られる ダーティーページ管理をしない 共有バッファはただのキャッシュ
11. つまり… 「25 % まで」にとどめる理由がなくなった もっと増やしても⾼速に処理できる
12. マサカリ求む︕ 本当のところはどうなの…︖
13. ありがとうございました