On 9-Oct-07, at 7:53 PM, Stu Hood wrote:
Using the filter cache method on the things like media type and
location; this will occupy ~2.3MB of memory _per unique value_
Mike, how did you calculate that value? I'm trying to tune my
caches, and any equations that could be used to determine some
balanced settings would be extremely helpful. I'm in a memory
limited environment, so I can't afford to throw a ton of cache at
the problem.
8bits * 25m docs. Note that HashSet filters will be smaller
(cardinality < 3000).
(I don't want to thread-jack, but I'm also wondering whether anyone
has any notes on how to tune cache sizes for the filterCache,
queryResultCache and documentCache).
I'll give the usual Solr answer: it depends <g>. For me:
The filterCache is the most important. I want my faceting filters to
be there at all times, as well as the common fq's I throw at Solr. I
have this bumped up to 4096 or so.
The queryResultCache isn't too important. I'm mostly interested in
keeping around a few recent queries since they tend to be
reexecuted. There is generally not a whole lot of overlap, though,
and I never page very far into the results (10 results over 100
slaves is more than I typically would ever need). Memory usage is
quite low, though, so you might have success going nuts with this cache.
docCache? Make sure this is set to at least maxResults*<max
concurrent queries>, since the query processing sometimes assumes
fetching a document earlier in the request will let us retrieve it
for free later in the request from the cache. Other than that, it
depends on your document usage overlap. It you have a set of
documents needed for meta-data storage, it behooves you to make sure
these are always cached.
cheers,
-Mike
