Thanks for the explanation. This makes a lot of sense to me... I'm wondering
if there's a way to get the best of both worlds. Can throwing more hardware
at the index give real time updates + a large LRU cache? Would we be CPU
bound at this point?
--
View this message in context:
Oh, what a lovely anti-pattern! Every second, you're throwing away your
filterCache. And then firing up to 4096 autowarm queries at your index
on the filterCache. And this doesn't even consider the other caches! And
this will get worse with time after restarts if my scenario is accurate.
Having
You havne't given us a lot of information to go on (ie: full
solrconfig.xml, log messages arround the tim of your update, etc...) but
my best guess would be that you are seeing a delay between the time the
new searcher is opened and the time the newSearcher is made available to
requests due
I'm not seeing any messages in the log with respect to cache warming at the
time, but I will investigate that possibility. Thank you. In case it is
helpful, I pasted the entire solrconfig.xml at http://pastebin.com/C0iQ7E9a
--
View this message in context:
: I'm not seeing any messages in the log with respect to cache warming at the
: time, but I will investigate that possibility. Thank you. In case it is
what logs *do* you see at the time you send the doc?
w/o details, we can't help you.
: helpful, I pasted the entire solrconfig.xml at
Immediately after triggering the update, this is what is in the logs:
/2014-08-12 12:58:48,774 | [71] | 153414367 [qtp2038499066-4772] INFO
org.apache.solr.update.processor.LogUpdateProcessor – [collection1]
webapp=/solr path=/update params={wt=json} {add=[52627624
(1476251068652322816)]} 0 34
Based on your solrconfig.xml settings for the filter and queryResult caches, I
believe Chris's initial guess is correct. After a commit, there is likely
plenty of time spent warming these caches due to the significantly high
autowarm counts.
filterCache class=solr.FastLRUCache
