evictions stat in 1.2.2

[Ben Hartshorne]

Hi,

After the previous thread about trying to see when you've overloaded
your cache and the conversations about the evictions metric, I wanted to
poke at the code and see if I could submit a patch to split out the
eviction stat to differentiate between cache overflows and expirations.

What I found doesn't match the documentation (so far as I can read it),
and I wanted some feedback as to whether I'm just reading the code wrong.

=======8<===== item.c ======8<=======8<======
    106     for (search = tails[id]; tries > 0 && search != NULL; tries--, search=search->prev) {
    107       if (search->refcount == 0) {
    108          if (search->exptime > current_time) {
    109              STATS_LOCK();
    110              stats.evictions++;
    111              STATS_UNLOCK();
    112         }
    113         do_item_unlink(search);
    114         break;
    115       }
    116     }
    117     it = slabs_alloc(ntotal);
    118     if (it == 0) return NULL;
=======8<===== item.c ======8<=======8<======

Here is the only place I see stats.evictions being incremented in the
code.  The way I read it, it only increments evictions when you are
removing an item that is not used and who's expiration time has not yet
been exceeded; i.e.  you have overflowed your cache.  (this is contrary
to the docs.  Am I reading it wrong?

This code also implies a few things.

First, it seems that refcount is incremented when you access the
stored item.  So the only way you can bump something is if it has never
been accessed, or if it has been accessed and then deleted (which
decrements refcount).  But if something has been accessed a few times,
it will never get bumped because it's only if search->refcount == 0 that
you will unlink the item.  

Second, it walks 50 elements up the chain looking for something to
unlink (that has refcount == 0), and that if the oldest  50 things all
have a reference, it gives up and your 'set' command fails.  

Next, it only frees one element, regardless of the size of the item you
want to put in the cache.  So if you insert a whole bunch of 5kb items
and fill up the cache, then want to drop in a 30kb item, it will notice
that it doesn't have enough space, free one 5kb item, try again to
allocate the space, fail a second time, and return failure, even if
there were more items with refcount == 0 that it could expire.


Are all these things correct?  

Thanks,

-ben

-- 
Ben Hartshorne
email: ben at hartshorne.net
http://ben.hartshorne.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.danga.com/pipermail/memcached/attachments/20070525/0714b73f/attachment.pgp