This is rather surprising. I know some defaults have changed between 1.4 and 4.0, so the first thing I'd do is try some of your sample queries with &debugQuery=on and compare the debug info to see if you're executing more complex queries without meaning to.
Also, dismax is deprecated in favor of edismax, so I'm not quite sure you're comparing apples/apples here. But it's worth pursuing. And I'm assuming you're measuring QTime rather than just measuring response time, although you did say jmeter, so I'd guess you're getting response times, not QTime. Best Erick On Thu, Jul 5, 2012 at 7:18 AM, Anatoli Matuskova <anatoli.matusk...@gmail.com> wrote: > Hello, > I'm testing solr-4.0-alpha compared to 1.4. My index is optimized to one > segment. I've seen a decrease in memory usage but a very high increase in > CPU. This high cpu usage ends up giving me slower response times with 4.0 > than 1.4 > The server I'm using: Linux version 2.6.30-2-amd64 16 2.26GHz Intel Pentium > Xeon Processors, 8GB RAM > I have a jmeter sending queries using between 1 and 4 threads. > The queries doesn't use faceting, neighter filters. Simple search to 5 text > fields using dismax > The index has 1M docs and is 1.2Gb size > I've checked memory with jvmconsole and it's not GC fault. > The index is built using the TieredMergePolicy for 4.0 and > LogByteSizeMergePolicy for 1.4 but both were optimized to 1 segment (so in > that case the merge policy shouldn't make any difference, am I correct?). > I'm not indexing any docs while doing the tests > Average response time came from 0.1sec to 0.3 sec > > Here is a graph of the cpu increase: > Any advice or something I should take into account? With the same resources > solr-4.0 is being 3 times slower than 1.4 and I don't know what I'm doing > wrong > > > > > http://lucene.472066.n3.nabble.com/file/n3993187/ganglia-solr.png > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/solr-4-0-and-high-cpu-usage-tp3993187.html > Sent from the Solr - User mailing list archive at Nabble.com.