mysqltunerのアドバイスに従ってQueryCacheを設定してましたが、このブログでは効果が薄いことが分かったので設定を解除しました。というお話です。
muninでQueryCache系の情報を可視化してみましたが・・・
不定期にmysqltunerを実行して効果を確認していると、たまにlowmem_prunes (QueryCacheのキャッシュを開放して空き容量を確保)が発生している時があります。発生タイミングを突き止めるためにmuninプラグイン化して状況を把握できるようにしてみました。
グラフ化により「キャッシュがあまり有効利用されていない」ことがわかりました。定期的にFLUSH QUERY CACHEを実行したりmysqlcheckでクエリキャッシュのクリアを行っているのですが、32MBのキャッシュ領域がみるみる減っているのがわかります。
無圧縮時のDBサイズは今のところ5MB程度なので、32MBもクエリキャッシュを使用することはないと思うのですが。
キャッシュが0になったタイミングのクエリ状況を見てみました。
6/6の12時頃にPS4メディアプレーヤーVer2の記事に結構な数のアクセスが集中していたのですが、その時にクエリキャッシュ領域を食いつぶしてしまったようです。特定の記事へのアクセスなのに、なぜクエリキャッシュが効かないのか・・・？
恐ら原因はランダム表示される「関連記事」の影響。
アクセスの度にランダム表示されるのでクエリキャッシュが効かないのだと思います。
QueryCacheを止めました
効果が無いならメモリの無駄なので、QueryCacheを6/6の22時くらいに止めてみました。
その結果がこちら。トップページのレスポンスタイムなのでランダム要素はないはずなのでクエリキャッシュはしっかり利いていると思っていましたが、6日以前と7日以降を見比べてもキャッシュ無効化の影響はほぼ0なようです。
グラフが上下に離れていると比較しづらいので重ねてみました。
やはり効果は無いようです。月間9,000PV程度のサイトやアクセスでは負荷が低すぎて意味が無いのか、あるいはWordPressとQueryCacheの相性が悪いのか・・・。現時点では情報が少なすぎて断定できませんが、効果がないのであればQueryCacheを無効化したままで経過を観察を行い、月間PV数が倍以上になったら。改めて一度効果を確認してみる予定です。
