You have a large index with tough performance requirements on one server. I would analyze your system to see if it's got any bottlenecks. Watch out for auto-warming taking too long so it does not finish before next commit() Watch out for too frequent commits Monitor mem usage (JConsole or similar) to find if the correct RAM is allocated to each JVM. How large is your index in terms of Gb? It may very well be that you need even more RAM in the server to cache more of the index files in OS memory.
Try to stop the Update JVM and let only Search-JVM be active. This will free RAM for OS. Then see if performance increases. Next, try an optimize() and then see if that makes a difference. I'm not familiar with the implementation details of StatsComponent. But if your Stats query is still slow after freeing RAM and optimize() I would file a JIRA issue, and attach to that issue some detailed response XMLs with debugQuery=true&echoParams=all , to document exactly how you use it and how it performs. It may be possible to optimize the code. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com On 9. mars 2011, at 11.39, stockii wrote: > i am using NRT, and the caches are not always warmed, i think this is almost > a problem !? > > ----- > ------------------------------- System > ---------------------------------------- > > One Server, 12 GB RAM, 2 Solr Instances, 7 Cores, > 1 Core with 31 Million Documents other Cores < 100.000 > > - Solr1 for Search-Requests - commit every Minute - 5GB Xmx > - Solr2 for Update-Request - delta every Minute - 4GB Xmx > -- > View this message in context: > http://lucene.472066.n3.nabble.com/getting-much-double-Values-from-solr-timeout-tp2650981p2654725.html > Sent from the Solr - User mailing list archive at Nabble.com.
