been fine just a few minutes earlier? If the latter, had
>> there been and system or JVM or Solr configuration changes between the time
>> queries were fast and when they became slow?
>>
>> Thanks.
>>
>> -- Jack Krupansky
>>
>> -Original Message-
Please review:
http://wiki.apache.org/solr/UsingMailingLists
Best
Erick
On Thu, Aug 16, 2012 at 11:41 PM, Sujatha Arun wrote:
> Hello,
>
> One of the Index in a multicore set up has a 3GB+ index ,and it seems to
> take around 5000ms to return simple boolean queries . The Index is not
> optmized
became slow?
>
> Thanks.
>
> -- Jack Krupansky
>
> -Original Message- From: Sujatha Arun
> Sent: Friday, August 17, 2012 10:50 AM
> To: solr-user@lucene.apache.org
> Subject: Re: Muticore Sharding
>
>
> Sorry typo ,I meant upwards of 20s at any time. What should I b
queries were fast and when they became slow?
Thanks.
-- Jack Krupansky
-Original Message-
From: Sujatha Arun
Sent: Friday, August 17, 2012 10:50 AM
To: solr-user@lucene.apache.org
Subject: Re: Muticore Sharding
Sorry typo ,I meant upwards of 20s at any time. What should I be looking at
Sorry typo ,I meant upwards of 20s at any time. What should I be looking at?
Regards
Sujatha
On Fri, Aug 17, 2012 at 8:09 PM, Sujatha Arun wrote:
> Erik,
>
> What could be the issue Load / I/O ? It seems to shows upwards of 20 ms
> at any time
>
> Regards
> Sujatha
>
>
> On Fri, Aug 17, 2012 a
Erik,
What could be the issue Load / I/O ? It seems to shows upwards of 20 ms at
any time
Regards
Sujatha
On Fri, Aug 17, 2012 at 6:18 PM, Erik Hatcher wrote:
> Sujatha - that query debug output shows only 218ms, so it isn't
> representative of the issue you're reporting.
>
> Also, what's the
Sujatha - that query debug output shows only 218ms, so it isn't representative
of the issue you're reporting.
Also, what's the query parse output? I imagine you're doing a boolean OR
query across all those terms (include "a"), yes? Maybe you'd rather the
operator be AND?
Erik
On A
No customization,its the default standard request handler.Solr Version is
1.3
"a" is not there in stop words
Server Load ,i presume is not there , but not too sure ,not checked.
RAM :
TOTAL RAM :48GB
RAM to JVM :18 GB ,Permgen =2GB
TOTAL INDEX SIZE of all the multicore Instances =23GB
Timing
Just over 4M docs... no need to shard.
Both your queries contain what is likely very common terms (content:a in the
first one and content:1 in the second). Generally these are "stop words" and
removed either during indexing or querying, but I guess not in your case.
What's your "standard" req
Hi Erick,
The number of documents is : 4389048
I have given 2 queries below with timing and the number of hits
INFO: [ipc_widget_search] webapp=/multicore_5 path=/select/
params={version=2.1&fl=*+score&stylesheet=&qt=standard&fq=&rows=100&start=0&q=content:if+content:elena+content:reads+content:
How many documents do you have? What are the queries? I'd guess your query
complexity (or load) is to blame here, not index size. What version of Solr?
Until you know what is causing the slow queries, sharding is not something to
consider I'd say. But yes, you would want to reindex to dist
11 matches
Mail list logo
