 |
||||||||||||||||||
|
||||||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||||||
|
||||||||||||||||||
| クエリキャッシュを使用した測定結果 | ||||||||||||||||||
|
必要な情報も出揃ったところで、クエリキャッシュをONにした状態での測定結果をみてみましょう。どの程度変化があったのかわかるように、クエリキャッシュをOFFにした状態での測定結果と並べたのが図1です。  図1：クエリキャッシュを使用した測定結果 （画像をクリックすると別ウィンドウに拡大図を表示します） これまでX軸は時系列でしたが、今回は別々の時間に測定した2つのデータの比較ですので、Super Smackで指定した同時接続数をX軸としています。 結果をみるとクエリが検索（SELECT）だけなので、かなり良い結果が得られたことがわかります。クエリキャッシュがOFFの場合のQueries_per_secは1,250程度でしたが、ONの場合は3,000程度となり、2倍以上の速度という結果でした。 |
||||||||||||||||||
| クエリキャッシュの保守 | ||||||||||||||||||
|
クエリキャッシュは手軽に設定でき、かつ効果が高いチューニング手法ですが、どの場面でも有効というわけではありません。ここでshow statusで得られる情報を軸に、クエリキャッシュの保守の方針を説明します。これにより、どのようなケースでクエリキャッシュが有効となり、かつ保守すればよいのかがみえてくると思います。 show statusで得られる情報には以下のようなものがあります。  （画像をクリックすると別ウィンドウに拡大図を表示します）
|
||||||||||||||||||
| クエリキャッシュの空き容量 | ||||||||||||||||||
|
Qcache_free_memoryはクエリキャッシュ用に割り当てたメモリの残量をあらわしています。query_cache_sizeの不足に関しては、この項目とQcache_lowmem_prunesを見ればわかります。つまりQcache_free_memoryが小さく、Qcache_lowmem_prunesが増加している場合には、query_cache_sizeの増量を検討すべきです。 |
||||||||||||||||||
| クエリキャッシュに入るクエリ、出て行くクエリ | ||||||||||||||||||
|
Qcache_insertsをみると、どの程度のクエリ数がキャッシュされているのかがわかります。このとき、クエリがキャッシュされるパターンには「まったく同一のクエリでなければ別のクエリとしてキャッシュされる」という性質は知っておく必要があるでしょう。 たとえばMySQLは以下の2つのクエリは別のクエリとしてキャッシュに登録します。
SELECT * from test.http_auth;
チューニングを行う際、この点を意識していないと無駄にキャッシュ領域を消費することになってしまいます。また逆にキャッシュから削除されることもありえます。これはテーブルに対して更新があった場合などで、そのテーブルに関連するキャッシュ内のクエリはすべてキャッシュから削除され、キャッシュの使用量は減少します。 ここで注意しなければならないのが、更新が多いサービスを提供している場合です。クエリキャッシュにデータが頻繁に出入りすることによって、それ自体がサーバの負荷となり、かえってキャッシュが原因で速度が劣化する可能性があります。クエリキャッシュの性能低下はQcache_hitsが芳しくなかったり、Qcache_lowmem_prunesが大きい結果がでることでわかります。こういうケースではクエリキャッシュを使わないか、キャッシュするクエリを更新頻度の低いものに限るようにするなどの対策が必要でしょう。 |
||||||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||||||
|
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
|
|
||||||||||||||||||
|
||||||||||||||||||
-
-
連載
