Yes, what you described is similar to the situation with the sessions not updated in memcached as they were only read by the application issue.
Still, I think if there's enough memory for all active sessions only sessions should be dropped that are in fact expired. For this a simplified slab configuration (one slab for all sessions) would be helpful AFAICS. Cheers, Martin On Sun, Mar 14, 2010 at 8:54 AM, Peter J. Holzer <[email protected]> wrote: > On 2010-03-12 17:07:25 -0800, dormando wrote: > > Now, it should be obvious that if a user session has reached a point > where > > it would be evicted early, it is because you did not have enough memory > to > > store *all active sessions anyway*. The odds of it evicting someone who > > has visited your site *after* me are highly unlikely. The longer I stay > > off the site, the higher the odds of it being evicted early due to lack > of > > memory. > > > > This does mean, by way of painfully describing how an LRU works, that the > > odds of you finding sessions in memcached which have not been expired, > but > > are being evicted from the LRU earlier than expired sessions, is very > > unlikely. > [...] > > The caveat is that memcached has one LRU per slab class. > > > > So, lets say your traffic ends up looking like: > > > > - For the first 10,000 sessions, they are all 200 kilobytes. This ends up > > having memcached allocate all of its slab memory toward something that > > will fit 200k items. > > - You get linked from the frontpage of digg.com and suddenly you have a > > bunch of n00bass users hitting your site. They have smaller sessions > since > > they are newbies. 10k items. > > - Memcached has only reserved 1 megabyte toward 10k items. So now all of > > your newbies share a 1 megabyte store for sessions, instead of 200 > > megabytes. > > There's another caveat (I think Martin may have been referring to this > scenario, but he wasn't very clear): > > > Suppose you have two kinds of entries in your memcached, with different > expire times. For example, in addition to your sessions with 3600s, you > have some alert box with an expiry time of 60s. By chance, > both items are approximately the same size and occupy the same slab > class(es). > > You have enough memory to keep all sessions for 3600 seconds and enough > memory to keep all alert boxes for 60 seconds. But you don't have enough > memory to keep all alert boxes for 3600 seconds (why should you, they > expire > after 60 seconds). > > Now, when you walk the LRU chain, the search for expired items will only > return expired alert boxes which are about as old as your oldest session. > As soon as there are 50 (not yet expired) sessions older than the oldest > (expired) alert box, you will evict a session although you still have a > lot of expired alert boxes which you could reuse. > > The only workaround for this problem I can see is to use different > memcached servers for items of (wildly) different expiration times. > > > However the slab out of balance thing is a real fault of ours. It's a > > project on my plate to have automated slab rebalancing done in some > usable > > fashion within the next several weeks. This means that if a slab is out > of > > memory and under pressure, memcached will decide if it can pull memory > > from another slab class to satisfy that need. As the size of your items > > change over time, it will thus try to compensate. > > That's good to hear. > > hp > > -- > _ | Peter J. Holzer | Openmoko has already embedded > |_|_) | Sysadmin WSR | voting system. > | | | [email protected] | Named "If you want it -- write it" > __/ | http://www.hjp.at/ | -- Ilja O. on [email protected] > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > > iD4DBQFLnJYsfZ+RkG8quy0RAqt8AJoCTvx1wPJE6Q4P7+rz8Pvi2l2HLgCYvhpa > SBop1pFUnyf6ODozse9kyA== > =c9w0 > -----END PGP SIGNATURE----- > > -- Martin Grotzke http://www.javakaffee.de/blog/
