> > we are trying to implement better memcached monitoring and have come > across this problem with 1.4.5: > > - after flush_all on a filled (long-running) memcached, we get > evictions immediately (within seconds, none of the buckets should fill > up that quickly) > > This would mean that either flushed items count toward evictions when > replaced (even though they should not be valid items after flush_all > and evictions should count only valid items that were replaced) or > that somehow flush_all does not work as expected, or that we have a > pathetically bad distribution of item sizes and memcached will not > reallocate slabs/buckets after a flush_all(?). > > If this behaviour is normal, does anyone have a better suggestion > regarding what to monitor other than evictions to see if more > memcached instances would be needed?
Huhhh I guess you're right. The evictions stat doesn't take into account if the item has been flushed, so they'll still show up as evictions. I'm not sure why you'd be doing flush_all to see if you need more memcached instances? Are you doing it often? If flush's are rare then the various evictions stats still mean something. Watch for evictions_nonzero and how old evicted_time is to see if you're probably running low on memory. Cross that with your hit rate and graph it. So if your hit rate starts fluctuating you should be able to trace it back to changes in traffic patterns or code pushes. Sometimes high eviction rates can mean you're shoveling in too many items that're never fetched again (but still set to expire after a long time). So it's a matter of watching these stats + being dilligent about what your app is doing. Would you mind opening a bug report about the evictions + flush_all thing? that's an easy fix. Thanks, -Dormando
