On 2/4/09 3:17 PM, "Mark Miller" <markrmil...@gmail.com> wrote:
> Walter Underwood wrote: >> Aha! I bet that the full Query object became a lot more complicated >> between Solr 1.1 and 1.3. That would explain why we did 4X as much GC >> after the upgrade. >> >> Items evicted from cache are tenured, so they contribute to the full GC. >> With an HTTP cache in front, there is hardly anything left to be >> cached, so there are lots of evictions. We get a query result cache >> hit rate around 0.12. >> >> wunder >> > At 10%, have you considered just not using the cache? Is that worth all > the extra work? Or are you not paying as much as your losing in GC/cache > time? I was going to verify the source of the tenured garbage before starting another round of trial-and-error tuning. Now that I have a good hunch, I might spend some time on that after the Oscars (our peak day for the year at Netflix). Another approach is to get fancy with the load balancing and always send the same query back to the same server. That increases the effective cache size by the number of servers, but it forces a simplistic round-robin load balancing and you have to be careful with down servers to avoid blowing all the caches simultaneously. At Infoseek, we learned that blowing all the caches when one server goes down is a very bad idea. wunder