Thanks for your response..<br><br>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. <br><br>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.
<br><br>- Stephen<br><br><div><span class="gmail_quote">On 2/27/06, <b class="gmail_sendername">Brad Fitzpatrick</b> <<a href="mailto:brad@danga.com">brad@danga.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
As designed. It expires things lazily as they're accessed or fall off the<br>LRU. It's designed to be all O(1), so things like trees/priority queues<br>for finding expired items to expire them ahead of time violate that.
<br><br><br>On Mon, 27 Feb 2006, Stephen Corgiat wrote:<br><br>> Hello,<br>><br>> We're seeing some weird behavior from memcached.. Hopefully somebody can<br>> provide some knowledge on this issue.<br>><br>
> When we set a key in memcache with a TTL of, say, 60 seconds, after 60<br>> seconds has gone by the data "expires". This is normal, but it seems the<br>> data is not truely freed by memcached (based on the 'bytes' stats field).
<br>> We've found that the only way to get the memory released is to try to do a<br>> GET on the key.<br>><br>> I always thought if you had a bunch of keys with a TTL of 0, once all<br>> available memory was consumed, memcache would start removing the least used
<br>> keys to make room for new keys. In our tests, this never happened.<br>><br>> We've tried installations on FreeBSD & Linux, 1.1.12 & 1.1.11... all with<br>> the same results.<br>><br>> Thanks!
<br>> Stephen<br>><br></blockquote></div><br>