stats cachedump
Anatoly Vorobey
mellon at pobox.com
Fri Jun 3 09:26:12 PDT 2005
On Fri, Jun 03, 2005 at 06:11:16PM +0200, Alexander Kjall wrote:
>
> > Space taken up by expired items is reclaimed if the item is looked up
> > for any request (get, set, etc.), or when there is no space left and
> > it's one of the items that haven't been requested for the longest time
> > (in that case, there is no difference between expired and non-expired
> > items w.r.t. reclaiming their space).
>
> Consider this senario: I have a large number of keys with low ttl and
> medium lookup-rate and some with long ttl and very low lookup-rate.
>
> Does this mean that expired keys with low ttl will push out nonexpired
> keys with long ttl.
If the expired keys are looked up relatively often, they will not
push out anything, because at the moment they're looked up, they're
freed (if they expired by that time).
What you describe could happen in a different setup: suppose you have
many keys with short expiration times that are looked up very rarely
*and* many keys with long expiration times that also are looked up very
rarely. If it so happens that for a long time no client looks at both
an expired item and an important non-expired item, it could happen that
the non-expired item will be pushed out first.
The output of 'stats items' includes "ages" of all item classes. "Age"
here means "this number of seconds ago the oldest item in this class,
the one that will be the first to be pushed out, was looked up".
If you are worried that important items that are looked up very rarely
might get pushed out (whether because of expired items or not --
actually in most installations expired items would only make a small
difference in this respect), you should monitor 'stats items' for some
time and make a note of your typical ages, and see if they are higher
than the lookup rate of your important items. If they're lower, the only
realistic thing to keep your important items from being pushed out is
to artificially request them more often.
In general, memcached never gives you a guarantee that an item you put
in will be there when you request it; you should always be able to
recreate it from the DB or from your other data. But if that is, for
instance, computationally expensive, then those items for which it
is very expensive could be called "important", and the considerations of
the previous paragraph apply.
--
avva
"There's nothing simply good, nor ill alone" -- John Donne
More information about the memcached
mailing list