TOP
＞
サーバ構築・運用
＞ key_buffer_sizeデチューン後の測定結果
はじめてのMySQLチューニング
第５回：key_buffer_sizeの違いによるパフォーマンス比較
著者：
アールワークス 田中 靖之
2007/7/30
前のページ
1
2
3
key_buffer_sizeデチューン後の測定結果
ここでは2つのグラフを並べてみましょう。
図1：key_buffer_sizeデチューン前の測定結果
（画像をクリックすると別ウィンドウに拡大図を表示します）
図2：key_buffer_sizeデチューン後の測定結果
（画像をクリックすると別ウィンドウに拡大図を表示します）
Queries_per_secについてはいつも通りですが、今回は左側Y軸をKey_read_requests/Key_readsの比率としました。ただしkey_buffer_sizeデフォルト状態での測定結果において実際には常にKey_reads=0で、ディスクからの読み込みはありませんでした。ですが、これでは比率を計算できませんので、Key_reads=1と仮定して計算しました。
デチューン後のグラフを見れば一目瞭然ですが、測定の最初からキーバッファが不足しており、Key_reads_requests/Key_reads比が30程度のまま推移しています。また比率が0になっている箇所がありますが、この際にはMySQLサーバが高負荷のため接続できずに測定不能でした。また、後半1/4以降も完全に測定不能でした。
以上から、キーバッファが埋まってしまうことは危険であることがわかります。もし各カラムのデータサイズがより大きければ、危険性がより高まることは間違いありません。
適切なkey_buffer_sizeの設定値を知るために
今回は検索のみであり、キーをすべてバッファ上に置くことができる環境でしたので、Key_read_requests/Key_reads比はとても理想的な値が出ています。ですが、実際の環境ではデータベースは常に更新（update、insert）や削除（delete）も行われており、常に必要なkey_buffer_sizeは変化しているはずです。
適切なkey_buffer_sizeを知るために、まず確認すべきはKey_block_unusedでしょう。これが数百ブロックといった小さな値になっている場合には増やす必要があります。デチューン後の測定では、Key_block_unusedが常に0だったので、不足していることは明白でした。
またKey_read_requests/Key_reads比にも注意しておくべきでしょう。デチューン後の結果のように、100を大きく割り込んでいる値が記録されている場合、key_buffer_sizeは不足しているはずですので、増やすことを検討すべきです。
なお、メモリに余裕があればとりあえずキーバッファに割り当ててしまえばよいのですが、実際には次回説明するquery_cacheやその他のグローバルパラメータ、またスレッドごとのパラメータが必要とするメモリとの兼ね合いも考える必要があります。
また意外と忘れがちですが、OSが動作するために必要なメモリとOS自身のディスクキャッシュ用にもある程度はメモリを残しておく必要があります。こちらはサーバ用途であれば、余裕を持って512〜1024Mbytes程度空けておけばよいでしょう。
前のページ
1
2
3
著者プロフィール
株式会社アールワークス 田中 靖之
ネットワークインテグレーション部
主にWebサービス系のシステム運用監視を担当するネットワークインテグレーション部に所属。システム改善やチューニングを顧客と共に考える姿勢を大事にしている。
INDEX
第5回：key_buffer_sizeの違いによるパフォーマンス比較
key_buffer_sizeとは
key_bufferの効果を確認する
key_buffer_sizeデチューン後の測定結果
