Aurora MySQL の Innodb_buffer_pool_size を変更する

いわさです。

Aurora MySQLで DBインスタンスを作成しました。
DBインスタンスサイズは db.r5.large。メモリ 16GiB RAM のものを選択しました。
しかし、起動後にモニタリングツールからFreeableMemory(メモリ使用可能量)を確認したところ約5GiB、想定していたサイズの4分の1程度です。

試しにDBインスタンスサイズの変更を行ってみます。
db.r5.2xlarge メモリ64GiB RAMへ変更してみます。

先程よりはメモリ使用可能量が増えましたが、期待値よりやはり低いです。
これは、どういうことでしょうか。

"Innodb_buffer_pool_size" によって、指定したインスタンスサイズよりも"FreeableMemory"が少なくなる

MySQLストレージエンジンである "Innodb" が テーブル、インデックスのデータをキャッシュするためにメモリー領域を確保するため少なくなります。
このキャッシュバッファープールサイズは、DBパラメータグループのInnodb_buffer_pool_sizeに設定値が存在します。

DBパラメータグループのデフォルト値は、"{DBInstanceClassMemory*3/4}"となっており、DBインスタンスのメモリサイズの4分の3をキャッシュバッファーとして確保します。
よって、残りの4分の1がメモリ使用可能領域として表示されていました。

パラメータ変更：静的パラメータなので再起動が必要

DBパラメータグループを変更してみましょう。

なお、デフォルトパラメータグループの場合は設定値の変更は出来ません。
後述しますが、DBパラメータはワークロードに応じてチューニングが必要な設定となりますので、個別のパラメータグループを作成し使用することをお勧めしますが、適用するパラメータグループは変更可能です。

変更直後は数値は変わりません。
パラメータには動的パラメータと静的パラメータの概念があり、本設定値は静的パラメータに該当します。
静的パラメータは起動時の初期処理でロードされるため適用には再起動が必要です。

DBインスタンスの設定値を見ると「再起動の保留中」となっていると思います。
では再起動を行い、メモリ使用可能量を確認してみます。

無事、変わりましたね。

Innodb_buffer_pool_size はどの程度の数値が適切か

ここで疑問に思うのが、デフォルトの4分の3という設定値は適切なのかどうか、です。
メモリキャッシュはデータベースのボトルネックになりやすいディスクIOを軽減することに大きな効果を持っています。
これは読み込み操作だけでなく、書き込み操作へも効果が発揮されます。

以下は Amazon RDS for MySQLにおけるパラメータ設定のベストプラクティスに関する記事です。

ここでは、アプリケーションが頻繁にアクセスするデータサイズはどの程度か、ワークロードの特性に応じて、個別にパラメータ値を設計するよう言及されています。
また、show engineコマンドでメモリバッファーを効率的に使用出来ているかの確認も行うことが推奨されています。

本日はメモリ使用可能量が想定より少なかった原因を探りたかったので、チューニングの実践までは行いません。

まとめ

メモリ使用可能量はキャッシュバッファーが確保された後の数値なので、その値のみを持って多い少ないという判断をしないように気をつけましょう。
また、パラメータ設定値はチューニングが必要です。 ワークロード特性に応じた設計と、使用状況の確認と見直しを行うようにしましょう。