you are right. It seems to be a combination of a limitation of default 
memcached and the ignorance of many users who just are not willing to 
click on the logout button.

And, yes I have now seen the "gc - TODO" comment in the source.



Too bad that the work around requires "hacking" the source code of 
memcached. This is even not documented, as far as I know. I guess in 
case of problems the memcached guys will tell us that this hack is not 
official and so unsupported.



A comment in slab.c says:

[...]

The last  slab size is always 1MB, since that's the maximum item size 
allowed by the memcached protocol.

Also, 1MB is (obviously) not a hard & fast limit, as this post makes clear:

http://lists.danga.com/pipermail/memcached/2006-January/001879.html

How many users do you have?  If you truly have tens of thousands of 
active users, and there really is a hard 1MB limit in memcache, there 
doesn't seem to be anything we can do about this.



If your sessions are not being terminated correctly - i.e. your users 
are not logging out properly - then you will probably need to run some 
sort of garbage collection method manually right now to clean out 
these old entries.  As the code indicates - garbage collection for 
session information in the class is todo, but hasn't yet been 
implemented.

It is of course the max. object size defined by the memcache protocol.



Didi



BTW: this can also happen in other places e.g. composing a message

'horde_memcache_sessions_track'  can get / gets bigger than 1048576 
bytes, which is the protocol defined object size for storable objects 
in memcached.

When this happens, session tracking using memcached is not working 
correctly. I get a lot of errors of the following kind:



Mon Jun 11 23:07:52 2007] [error] [client xxx.xxx.xxx.xxx] PHP Notice: 
  Memcache::set() [<a 
href='function.Memcache-set'>function.Memcache-set</a>]: marked server 
'xxx.xxx.xxx.xxx:11211' as failed in 
/usr/local/lib/php/Horde/Memcache.php on line 151



And, YES I enabled compression.