RDS側
- インスタンスサイズ（db.t3.microなど）
- RDSのバージョンアップ前後のバージョン番号
- パラメータグループがデフォルトかカスタムか
- CloudWatchの
FreeableMemoryとDatabaseConnectionsの推移グラフ - スロークエリログが有効になってるか
アプリ側
- フレームワーク（Flask？Django？）
- DB接続まわりのライブラリとバージョン（SQLAlchemyなど）
アラート設定
- FreeableMemoryのアラート閾値がいくつか
これだけ持ってくれば原因の見当がつきます。
情報整理します。
状況
- db.m5.large はメモリ8GBのインスタンス
- FreeableMemory 400〜600MB ということは7.4〜7.6GBが使われてる状態
- 閾値430MB、FreeableMemoryが400MBまで下がることがあるのでアラートが鳴る
- 接続数9〜30は全然少ないのでコネクション問題ではない
怪しいのはカスタムパラメータグループ
MySQLはデフォルトで innodb_buffer_pool_size をメモリの75%くらい使う設定になっています。カスタムパラメータグループでここが大きく設定されてると、それだけでメモリをほぼ使い切ります。
次に確認すること
- カスタムパラメータグループの
innodb_buffer_pool_sizeの値
あとバージョンアップ（8.4系）でメモリ管理が変わった可能性もあるので、バージョンアップ前のバージョン番号もわかると比較できます。
innodb_buffer_pool_sizeの確認方法
AWSコンソールで：
- RDS → パラメータグループ → カスタムグループを選択
innodb_buffer_pool_sizeを検索
または MySQLに接続して：
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';
値によって次にやること
db.m5.largeのメモリは8GBなので：
- 6GB以上に設定されてる → 大きすぎるので5〜6GB（75%くらい）に下げる
- デフォルトのまま → バージョンアップ8.4の仕様変更を調べる方向
パラメータグループの値変えるだけなら再起動不要なものもありますが、innodb_buffer_pool_size は再起動が必要なので変更前に確認が必要です。
コメント