stats の出力をもっと注意深く見る。
stats でぞろぞろ出てくる物の中に bytes の項目がある。 protocol.txt によると
bytes 64u Current number of bytes used by this server
to store items
とあるので、これが実際いま保存されているキャッシュオブジェクトの総量ということになるのかな。
そして memcached プロセスが確保済みの（しかしそのうち何パーセントくらい使い切れているのかはわからない）メモリ総量は stats slabs で出てくる total_malloced の数字のように思える。
total_malloced Total amount of memory allocated to slab pages.
とある。
つまり、第一段階として、 memcached プロセス全体でどのくらい効率良く確保したメモリにキャッシュを保存できているか？は、 bytes / total_malloced で求められる、んじゃないかなあ。
そして次に、各 slab ごとにどのくらい「埋まって」いるのかを調べるために、 stats sizes の出力結果もとに、 stats slabs の単位ごとに item をグループ分けして、かけてたしてわれば、ある slab が何パーセントくらい「埋まって」いるのかがはじき出せる、んじゃないかなあ。そしてあまり埋まってない slab がなくなるような factor の値を見つければ、キャッシュの効率をより良くできる、んじゃないかなあ・・・。
さらにここに max_ages が絡んでくるよていなのだけど、そこまで一気に考えるとパンクしてしまって思考停止してしまう。。ので、「max_ages が短いのには二種類あって、一つは更新が頻繁なキャッシュの種類だっていうケース、これはどうしようもない、もう一つが、本来その slab に入る必要がないのにぴったりの slab がなくて仕方なく過剰に大きい slab に保存されちゃってるから競争率が高くなって max_ages が落ちる、というケース、こちらを改善したくて、それは slab をちょうどよく細かく分割できれば自然に解決するはずだ！！」と考えることにする。
