MySQL InnoDBストレージエンジンのチューニング(後編)

EnterpriseZine / 2012年3月16日 0時0分

前回は、InnoDBのチューニングをするために知っておくべきInnoDBの特徴と基本的な構造についてごく簡単に紹介した。それらを踏まえた上で、今回はInnoDBをどのようにチューニングするかについて解説しよう。新しい用語も出てくるが、それらについては本稿において説明しているので安心して欲しい。まだ前回のエントリを読んでいないというひとは、まずそちらに目を通して頂きたい。

■チューニングの基礎

 それでは、具体的にInnoDBでどこをチューニングするべきかを見ていこう。
バッファプール

 最も基本となるのがバッファサイズの調整だ。ワーキングセットが全てバッファに収まらない限り、バッファプールは大きければ大きいほど良い。その分ディスクアクセスが減るからだ。バッファサイズが小さいと、キャッシュミス時にディスクからReadするのに時間がかかり、I/Oがボトルネックになってしまう。予算のある限りメモリを目いっぱい搭載し、バッファプールに割り当てよう。InnoDBのバッファプールは、innodb_buffer_pool_sizeオプションで設定する。利用可能なメモリは、他の処理に必要な分を除いたすべてをInnoDBのバッファプールに割り当てよう。

 innodb_buffer_pool=32G

 ここで一つ注意がある。innodb_buffer_pool_sizeはバッファプールそのもののサイズを指定するオプションだが、InnoDBはバッファプールのサイズに比例してメモリを消費するオブジェクトが存在する。そのため、innodb_buffer_pool_sizeよりも5~10%ほど多くメモリを消費するということを覚えておこう。
ログの調整

 InnoDBでは、全ての変更はバッファプール上で行われ、後から遅れてバッファプールの内容がテーブルスペースへ書き込まれる。そして、永続性を保証するためにログに更新した内容を記録するようになっている。ログへの更新はシーケンシャルな書き込みになるためテーブルスペースへの書き込みに比べると高速だからだ。

 すると、必然的に「ログファイルおよびバッファプール上には存在するが、テーブルスペースには存在しない」というデータが生じることになる。そのようなデータを含んだページは「ダーティページ」と呼ばれる。当然、MySQLサーバーやOSがクラッシュすると、再起動後にはバッファプール内のデータは全て失われる。ここが重要なポイントなのだが、ダーティページのデータを復元するにはログにデータが存在している必要がある。そのため、どれだけのダーティページが存在できるかは、ログファイルのサイズにかかっている。ダーティページが増えすぎ、ログファイルの空き容量がなくなると、さらに更新を続けるためにはまずダーティページをテーブルスペースへフラッシュする必要がある。そうしなければ新たに更新によってダーティページを生成することができないからだ。

  • 前のページ
    • 1
    • 2
  • 次のページ
EnterpriseZine

トピックスRSS

ランキング