We've observed a correlation between our cache rate decreasing and a spike in cache ready busy failures (proxy.process.cache.read_busy.failure), though I've yet to determine the cause for this.
What I really don't understand is why restarting resolves the issue for about 24 hours? I know the hash of directories is stored in memory…is there anything else that would be rebuilt on a restart related to caching? From: Peter Walsh <[email protected]<mailto:[email protected]>> Reply-To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Fri, 25 Jan 2013 23:51:59 -0800 To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Issue with cache hit ratio degradation over time, restart resolves temporarily Hello all, Lately we have been experiencing an odd issue with our cluster running 3.2. After about 24 hours we'll see a 10-20% drop in cache hit ratio, which will hold steady for several hours before dropping again another 10-20% in what looks like stair step. Eventually, it will drop to almost 0%. Whats *really* odd is that restarting the cluster temporarily resolves the issue, bringing the cache hit ratio back to normal levels for another day or so. We've added more cache space but that has shown no change in behavior. Memory, disk space, and CPU utilization is normal. The only difference in usage I've identified, is our use cases in which we use the Cache API in our plugin have increased. Any thoughts anyone? Thanks in advance.
