curr_items never decreases

Brian Moon brianm at
Thu May 18 14:46:12 UTC 2006

> There shouldn't be a significant performance penalty for keeping this 
> value properly up to date though...

Yes, there is.  What has to happen to keep it up to date?  memcached has 
to go through its cache and count expired items.  When does it do this? 
  The only time memcached looks at a piece of cache is when it is asked 
to.  Other than that, its just a chunk of memory.  Adding a process to 
cycle through the cache and do housekeeping would add an unwanted 
performance hit.

I am always curious when people ask this question.  I have seen similar 
questions about the expired cache off and on since I joined this list. 
I don't mean to come off like a smart ass, but what is it that makes you 
feel you need to know the raw number of unexpired items in your cache? 
our cache has 727,929 items spread across 8 servers.  I only have that 
stat on a stats page because it is available to me.  Perhaps if I 
understood more what is driving this quest for this knowledge, we can 
all better help future people that will ask this question.

For me, the key is in our hit/miss and cache free numbers:

Hits: 641,417,353
Misses: 9,052,475
Cache Free: 198.82M

We have free cache, so that means that we are not rolling stuff off 
before its expiring.  Our hit/miss ratio tells me that we are not 
creating lots of unique keys that will never get hit again.  So, IMO, 
our cache is healthy.  Those servers have been running since 4/25 
without a flush.  We only had to flush them then because we made a 
change to something and wanted the cache out sooner than the expire time.

(Heh, 71:1 hit/miss ratio.  What did I say before?  900? sorry.  that is 
what happens when you pull numbers off the top of your head.)


Brian Moon
Its good to be cheap =)

More information about the memcached mailing list