Here is the response to your 2 questions: 1- Started from fresh Solr 4 config and modified custom stuff.
2- Index is same and optimized. However, as I said in a previous mail the issue seems to be Surround Query Parser which is parsing the query in a different format. On Thu, Dec 5, 2013 at 2:24 PM, Daniel Collins <danwcoll...@gmail.com>wrote: > Not sure if you are really stating the problem here. > > If you don't use Solr sharding, (I also assume you aren't using SolrCloud), > and I'm guessing you are a single core (but can you confirm). > > As I understand Solr's logic, for a single query on a single core, that > will only use 1 thread (ignoring updates, background merges, etc). A > Lucene index (with multiple segments) has each segment read sequentially, > so a search must scan all the segments and that inherently is a > single-threaded activity. > > The fact that the search uses less CPU is not really the issue (it might > actually be a GOOD thing, it could mean the code is more efficient!), so I > would consider that a red herring. The real issue is that the search takes > longer in elapsed time. > > The usual questions apply: > > 1) how did you upgrade, did you port your config, or start from a fresh > Solr 4 config and add your custom stuff to it. > 2) Is your new index comparable to your old one, does it have more > segments, how did you fill it (bulk import or upgrade of old 1.4.1 index), > and what is your merge policy for the index? > > Upgrades from such an old version of Solr have been asked before on the > list, the consensus is that you probably need to re-tune your configuration > (starting with a Solr 4 basic config) since Solr 4 is so different under > the hood from 1.x > > > On 5 December 2013 09:11, Salman Akram > <salman.ak...@northbaysolutions.net>wrote: > > > More info on Cpu consumption: We have a server with 32 physical cores. > > > > Same search when executed on SOLR 4.6 takes quite long and throughout > only > > uses 3% cpu (1 core). > > > > Same search when executed on SOLR 1.4.1 takes much less time and on > average > > uses around 40-50% cpu. > > > > > > On Thu, Dec 5, 2013 at 2:05 PM, Salman Akram < > > salman.ak...@northbaysolutions.net> wrote: > > > > > I missed one imp piece of info. Due to large size we have indexed the > > date > > > with Common Grams. All of the words in slow search are in common grams > > and > > > when I debug it, they query is made properly with common grams. > > > > > > In debug all of the time is shown in process query time. > > > > > > Let me know what other info you need? Thanks > > > > > > > > > On Thu, Dec 5, 2013 at 11:38 AM, Andrea Gazzarini < > agazzar...@apache.org > > >wrote: > > > > > >> Hi, I did moreless the same but didn't get that behaviour...could you > > give > > >> us more details > > >> > > >> Best, > > >> Gazza > > >> On 5 Dec 2013 06:54, "Salman Akram" < > salman.ak...@northbaysolutions.net > > > > > >> wrote: > > >> > > >> > Hi, > > >> > > > >> > We recently upgraded to SOLR 4.6 from SOLR 1.4.1. Overall the > > >> performance > > >> > went down for large phrase queries. On some analysis we have seen > that > > >> > 1.4.1 utilized multiple cpu cores for such queries but SOLR 4.6 is > > only > > >> > utilizing single cpu core. Any idea on what could be the reason? > > >> > > > >> > Note: We are not using SOLR Sharding. > > >> > > > >> > -- > > >> > Regards, > > >> > > > >> > Salman Akram > > >> > > > >> > > > > > > > > > > > > -- > > > Regards, > > > > > > Salman Akram > > > > > > > > > > > > -- > > Regards, > > > > Salman Akram > > > -- Regards, Salman Akram
