MariaDB Buffer Poolサイズのチューニング¶

概要¶

Buffer Poolは、頻繁にアクセスされるデータをメモリ上に保持するための領域であり、安定した性能を維持するためには十分なサイズを確保する必要があります。
本事例では、統計情報の分析結果により、このBuffer Poolの容量が不足している状況が確認されました。
そこで本ドキュメントでは、容量不足と判断にいたった調査内容と、メモリの使用状況を踏まえてBuffer Poolサイズを見直した事例について紹介します。

警告

最適なBuffer Poolサイズはデータサイズやアプリケーションからのアクセス特性によってシステムごとに異なります。
また、Buffer Poolのチューニングは、一度の調整で完了するものではありません。
「サイズ変更 → 処理実行 → 統計情報確認」を繰り返し実施し、調整後も継続的に統計情報を確認しながら適切なサイズを維持することが重要です。

前提¶

ITA バージョン: 2.8.0
Platform バージョン: 1.12.0
インストール環境: Kubernetes
DB：MariaDB
ストレージエンジン：InnoDB
MariaDBのメモリサイズ：16GB
Buffer Poolサイズ：2GB

Buffer Poolの状況確認¶

Buffer Poolの利用状況を把握するため今回は以下の2つの統計情報に着目して、分析を行いました

統計情報	説明
`Innodb_buffer_pool_pages_free`	Buffer Pool内の空きページ数。値が0に近い場合、Buffer Pool内の空き領域が少ない状態であることを示します。
`Innodb_buffer_pool_wait_free`	新しいデータを読み込むために空きページを確保しようとしたが、空きがなく解放されるのを待機した回数。この値が継続的に増加している場合、Buffer Pool不足が発生していることを意味します。

注釈

統計情報は、通常運用時など、「想定される処理負荷がかかっている」状態で取得してください。

これらの値を確認するため、通常の運用状態で計4回、以下のコマンドを実行しました。

SHOW GLOBAL STATUS;

実行例（出力イメージ）:

+--------------------------------+-------+
| Variable_name                  | Value |
+--------------------------------+-------+
|  Innodb_buffer_pool_pages_free |  0    |
|  Innodb_buffer_pool_wait_free  |  1987 |
+--------------------------------+-------+

確認結果

Innodb_buffer_pool_pages_free は 1、0、0、702 で推移しており、4回中3回は空きページ数が1以下であり、空きページが極めて少ない状態でした。
Innodb_buffer_pool_wait_free は 1859、1886、1987、2205 と継続的に増加しており、空きページ確保の待機が発生していました。

以上から、Buffer Poolの空き領域が枯渇していると判断しました。

空きページの確保待ちが発生するとページの読み込み処理が滞るため、クエリの実行速度が低下する要因となります。

メモリ使用量の確認¶

Buffer Poolを拡張するにあたり、拡張に充てられるメモリの余裕があるかを確認するため、MariaDB Podのメモリ使用量を調査しました。

Kubernetes環境では標準でPodのメモリ使用量を取得できないため、Metrics Serverを導入した上で、以下のコマンドを実行して確認しました。

kubectl top pod -n <namespace>

上記コマンドで表示されるPod一覧の中から、MariaDBのPodの使用量を確認します。

MariaDBのPodには16GBを割り当てていますが、実際のメモリ使用量は3～4GBで推移していることを確認しました（Buffer Poolの拡張に充てられるメモリの余裕は十分にある状況）。

サイズ設定の考え方¶

Buffer Poolのサイズは innodb_buffer_pool_size で設定します。
現状のメモリサイズは16GBであり、直近のメモリ使用状況は3～4GBで推移していることから、おおよそ12GB程度の空きがあると考えられます。
この余剰メモリを前提として、現行の2GBから段階的にサイズを拡張する方針としました。

第一段階（4GB）¶

MariaDB内の全データサイズ（全テーブルサイズの合計）は約8.5GB(※)であったため、その約半分にあたる4GBを初回拡張サイズとしました。

(本案件では、DBアクセスが多数のテーブルに分散しており、特定のデータに偏らないアクセスパターンであったため、全データの約半分を一つの目安としています。)

※全データサイズは、以下のSQLでテーブル単位のサイズを取得し、その合計値から算出しました。

なお、t_audit_log は膨大で計測時に負荷がかかるため、本事例では除外しています。

SELECT
    table_schema AS 'データベース名',
    table_name   AS 'テーブル名',
    table_rows   AS 'レコード数',
    ROUND((data_length + index_length) / 1024 / 1024, 2) AS 'サイズ(MB)'
FROM
    information_schema.TABLES
WHERE
    table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')
    AND table_name != 't_audit_log'
ORDER BY
    table_schema, table_name;

上記で得られた約8.5GBを基に、その約半分を初回拡張サイズとしました。

8.5GB × 約50% ≒ 4GB

第一段階のサイズ変更後は、再度 Buffer Poolの状況確認 のセクションで示した統計情報を取得し、待機が発生しなくなるまで同様のサイクルを繰り返して段階的にチューニングを進めてください。

まとめ¶

本事例では、統計情報を通じてBuffer Pool不足を確認し、メモリ使用状況に余裕があることを踏まえて、Buffer Poolサイズを段階的に拡張する方針としました。

Buffer Poolサイズは一度設定して終わりではなく、統計情報を継続的に取得しながら、利用状況の変化に応じてチューニングを検討していくことが必要です。

↑ Page Top