Hi,
probably this may help you start:
https://issues.apache.org/jira/browse/SOLR-1297
Dmitry
On Mon, Jun 4, 2012 at 9:51 PM, Gau wrote:
> Here is the usecase:
> I am using synonym expansion at query time to get results. this is
> essentially a name search, so a search for Jim may be expanded
g it took from 30 mins up to 2 hours).
>>>
>>> Slave caches are configured to have autowarmCount="0" and
>>> maxWarmingSearchers=1 , and I have new data 1 second after snapshoot is
>>> done. I haven't noticed any huge delays while serving search r
xWarmingSearchers=1 , and I have new data 1 second after snapshoot is
>> done. I haven't noticed any huge delays while serving search request.
>> Try to use those values - may be they'll help in your case too.
>>
>> Ben Janicki
>>
>>
>> -Origin
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: 22 October 2008 04:56
To: solr-user@lucene.apache.org
Subject: Re: Sorting performance
: The problem is that I will have hundreds of users doing queries, and a
: continuous flow of document coming in.
: So a delay in warming up a cache "co
Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: 22 October 2008 04:56
To: solr-user@lucene.apache.org
Subject: Re: Sorting performance
: The problem is that I will have hundreds of users doing queries, and a
: continuous flow of document coming in.
: So a delay in warming up a cache "could&qu
lp in your case too.
Ben Janicki
-Original Message-
From: Chris Hostetter [mailto:[EMAIL PROTECTED]
Sent: 22 October 2008 04:56
To: solr-user@lucene.apache.org
Subject: Re: Sorting performance
: The problem is that I will have hundreds of users doing queries, and a
: continuous flow of d
: The problem is that I will have hundreds of users doing queries, and a
: continuous flow of document coming in.
: So a delay in warming up a cache "could" be acceptable if I do it a few times
: per day. But not on a too regular basis (right now, the first query that loads
: the cache takes 150s)
I'm now considering if Solr (Lucene) is a good choice when we have a
huge number of indexed document and a large number of new documents
needs to be indexed everyday.
Maybe I'm wrong, but my feeling is that the way the sort caches are
handled (recreated after new commit, not shared between Sea
inal Message-
From: Mark Miller [mailto:[EMAIL PROTECTED]
Sent: Monday, October 20, 2008 6:24 AM
To: solr-user@lucene.apache.org
Subject: Re: Sorting performance
christophe wrote:
> When I start indexing new documents, searches are taking long time
> again: is the sort cache flushed when new
The problem is that I will have hundreds of users doing queries, and a
continuous flow of document coming in.
So a delay in warming up a cache "could" be acceptable if I do it a few
times per day. But not on a too regular basis (right now, the first
query that loads the cache takes 150s).
Howe
On Mon, 20 Oct 2008 16:28:23 +0300
christophe <[EMAIL PROTECTED]> wrote:
> Hum. this mean I have to wait before I index new documents and avoid
> indexing when they are created (I have about 50 000 new documents
> created each day and I was planning to make those searchable ASAP).
you can a
Hum. this mean I have to wait before I index new documents and avoid
indexing when they are created (I have about 50 000 new documents
created each day and I was planning to make those searchable ASAP).
Too bad there is no way to have a centralized cache that can be shared
AND updated when n
christophe wrote:
When I start indexing new documents, searches are taking long time
again: is the sort cache flushed when new documents are indexed ?
When you commit, a new Reader will be opened (or reopened) so that the
freshly added docs can be seen. This would make the first search slow
a
Caches are specific to opening a searcher. So whenever you open a reader,
the caches are rebuilt for that server. If you are picking up your changes,
you
MUST be opening a new reader so yes, indeed, your caches are being flushed.
You can get around this by firing a few warmup queries at the server
When I start indexing new documents, searches are taking long time
again: is the sort cache flushed when new documents are indexed ?
Thanks
Christophe
Mark Miller wrote:
You need to setup a warming query that sorts so that the initial long
query is done behind the scenes. Users first query wil
Will do so. Thanks.
Are there any metrics on how to compute memory requirements (based on
doc average size, number of sorted fields, number of indexed documents +
number of new document / day) ?
Thanks
Christophe
Mark Miller wrote:
You need to setup a warming query that sorts so that the ini
You need to setup a warming query that sorts so that the initial long
query is done behind the scenes. Users first query will then be fast.
Solrconfig.
- Mark
On Oct 18, 2008, at 1:34 AM, christophe <[EMAIL PROTECTED]>
wrote:
Here are the memory parameters I'm using now(Tomcat): -Xms202
Here are the memory parameters I'm using now(Tomcat): -Xms2024m -Xmx2024m
With those values, the second query is way faster. Only the first one is
very slow.
Thanks for the tip.
However, I'm wondering if will be enough and I will not hit the same
issues when I will have many users searching at
It is slow each time I run it. (I test it from the Solr admin console or
from a JAVA program using the Http client).
I do not get the OOM each time.
Thx
Christophe
Otis Gospodnetic wrote:
Is the sorted query slow only the first time or every time you run it?
You got an OOM? What -Xmx value a
Is the sorted query slow only the first time or every time you run it?
You got an OOM? What -Xmx value are you using? Try increasing it.
Otis
--
Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
- Original Message
> From: christophe <[EMAIL PROTECTED]>
> To: solr-user@lucene
20 matches
Mail list logo
