I've found its ok if the cache never hits cache full.  By storing less stuff it manages to store more items despite the fragmentation.

I was experiencing the same thing on 3.0.19! Php-spawner (php-fpm or php-cgi standalone) Just stalled when APC hit 100% cache. And it was impossible to guess the problem, luckely guessing it was APC and checking this bug report confirms it.

Regarding the fragmentation I can confirm this on 3.1.3p1  (where in 3.0.19 it was much much 'cleaner'). No crash yet which is great, and I have no input on it not using 100% of the memory when reaching the limit yet...

http://img194.imageshack.us/img194/1395/apc.png

My cache has now reached it's maximum and can say that APC cleared ALL cache. This isn't the behaviour I was expecting. I have loads of small cache that are suppsed to expire since they have a ttl. After their ttl they should be overwritten with new cache sets thus I should never use 100% of the memory (since I never did before with memcache). The cache sets that have 0 ttl should NEVER get deleted (as they do with the clear when 100% was reached).

Hoping this will be sorted out in some way or I'll have to go back to memcached where it worked, but speedwise isn't near APC cache...

The TTL is used for opportunistic cache expiration.  It is 
not used when the cache hits %100 full.  It is simply too 
slow to walk through the entire cache looking for entries to 
TTL out.  When we hit 100% (which you should try hard to 
avoid) we dump the entire cache because that can be done 
quickly.

The user cache was not designed to hold a lot of short 
expiry entries.  The single lock design simply doesn't 
support that.  It is for very static blocks of data that 
ideally doesn't change for weeks.

Thanks rasmus for the clarification. I understand having a garbage collector that checks all the ttl's would be a performance killer. I'll just rethink my cache strategy so that it doesn't consume that much memory.

But basically the ttl has no inpact on the memory usage, assigned to APC, other than if another cache->set is done in the 'future'? Then it will be replaced (cleared/re-used) if it was set weeks ago?

Like I said, it is used for opportunistic expiration.  That 
means that if in the case of hash collision either on a 
lookup or an insert we happen to come across an expired 
entry, we will remove it.  You can improve the odds of 
getting a lot of hash collisions by reducing the number of 
hash slots, with the trade-off of course being that the more 
hash collisions you have, the slower it will be since it 
will have to walk the linked list of entries tied to that 
hash.  But you will improve your opportunistic garbage 
collection.

I'm in the process of deploying a new Ubuntu 10.04 server for our web cluster and I noticed a rather extreme memory fragmentation.
Screenshot from APC's control panel: http://imgur.com/LU1Gh.png
Screenshot from eAccelerator's control panel: http://imgur.com/od1SN.png
Both servers are configured for 256MB cache size. Both servers are in the same web-cluster serving identical content.
APC's ttl and gc are set to 600.

Definitely still the same issue with APC 3.1.4 

As soon as "Cache full count reaches" '1' in APC's console 
APC's shared memory segment is entirely unreliable -- 
apc_store reports it's able to store data, that you can't 
immediately apc_fetch, apc_delete() reports that it worked 
when you can then immediately apc_fetch the data back out, 
so both are not even telling you they failed.  

The only workaround to which I've found is clearing the 
cache entirely / reloading apache.

Likely the reason more people don't notice this is that it's 
insidious -- none of my defensive code to check return codes 
from apc_store and apc_delete is ever hit, and we use it 
strictly for cache so it's data that can be pulled if it 
fails.

Why wasn't this a problem in the 3.0 series?  We'd like to use 
the 3.1 for the inc feature, but this is blocking us, as we do 
have many small counters than get flushed every 15 minutes.

I checked out this bug - this only chokes if apc_bin_* functions are used.

That pools all allocations for an entire cache-set, so the memory for expiring entries are not cleaned up (because it's a single allocation). 

If you aren't using apc_bin_* functions, re-open the bug. I will be fixing the documentation about it, soon.

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.