Memcache not freeing memory when a key expires

Stephen Corgiat nitelord at gmail.com
Tue Feb 28 02:27:16 UTC 2006


Thanks for your response..

Good to know if this was really the way it was supposed to work, hopefully
someone else finds this if they're wondering the same thing.

Since we love memcached so much and would like to continue using it for our
site, we decided to code in a "reaper" command which deletes keys that have
expired.  We're testing it out and so far so good.

- Stephen

On 2/27/06, Brad Fitzpatrick <brad at danga.com> wrote:
>
> As designed.  It expires things lazily as they're accessed or fall off the
> LRU.  It's designed to be all O(1), so things like trees/priority queues
> for finding expired items to expire them ahead of time violate that.
>
>
> On Mon, 27 Feb 2006, Stephen Corgiat wrote:
>
> > Hello,
> >
> > We're seeing some weird behavior from memcached.. Hopefully somebody can
> > provide some knowledge on this issue.
> >
> > When we set a key in memcache with a TTL of, say, 60 seconds, after 60
> > seconds has gone by the data "expires".  This is normal, but it seems
> the
> > data is not truely freed by memcached (based on the 'bytes' stats
> field).
> > We've found that the only way to get the memory released is to try to do
> a
> > GET on the key.
> >
> > I always thought if you had a bunch of keys with a TTL of 0, once all
> > available memory was consumed, memcache would start removing the least
> used
> > keys to make room for new keys. In our tests, this never happened.
> >
> > We've tried installations on FreeBSD & Linux, 1.1.12 & 1.1.11... all
> with
> > the same results.
> >
> > Thanks!
> > Stephen
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.danga.com/pipermail/memcached/attachments/20060227/6babdb77/attachment.html


More information about the memcached mailing list