,
>
> I got some Lucene indexes in my project, mostly of them are created once and
> updated, not so frequently, about once a week or monthly. The indexes sizes
> are about 20GB and as more inserts are done the indexes grow, so I'd like to
> know what the best index opti
Hello folks,
I got some Lucene indexes in my project, mostly of them are created once and
updated, not so frequently, about once a week or monthly. The indexes sizes are
about 20GB and as more inserts are done the indexes grow, so I'd like to know
what the best index optimization strate
: My understanding is that an optimized index gives the best search
there is an inherent inconsistency in your question -- yo usay you
optimize your index before using it becuase you heard thta makes searches
faster, but in your orriginal question you said...
> I'd like to shorten the time it
I'll run some tests. Thank you.
> From: [EMAIL PROTECTED]
> To: java-user@lucene.apache.org
> Subject: Re: Index optimization ...
> Date: Wed, 30 Jul 2008 11:12:28 -0400
>
> What version of Lucene are you using? What is your current
> mergeFactor? Lowering this (mi
it make the indexing slower (which I'm OK with)
but the optimization faster? Thank you.
Date: Tue, 29 Jul 2008 08:32:46 +0200
From: [EMAIL PROTECTED]
To: java-user@lucene.apache.org
Subject: Re: Index optimization ...
John Griffin:
Use IndexWriter.setRAMBufferSizeMB(double mb) and
ge factor.
>
>> Date: Wed, 30 Jul 2008 15:03:37 +0100
>> From: [EMAIL PROTECTED]
>> To: java-user@lucene.apache.org
>> Subject: Re: Index optimization ...
>>
>> OK, but why do you need to optimize before every swap? Have you tried
>> with less frequent op
t;new" inactive upto speed
to compensate for the documents it missed while the "old" Inactive index got
upated?
Just curious,
Anand
-Original Message-
From: Dragon Fly <[EMAIL PROTECTED]>
Date: Wed, 30 Jul 2008 10:00:25
To:
Subject: RE: Index optimization ...
I have t
Jul 2008 15:03:37 +0100
> From: [EMAIL PROTECTED]
> To: java-user@lucene.apache.org
> Subject: Re: Index optimization ...
>
> OK, but why do you need to optimize before every swap? Have you tried
> with less frequent optimizes?
>
> --
> Ian.
>
>
> On Wed, Jul
+0100
>> From: [EMAIL PROTECTED]
>> To: java-user@lucene.apache.org
>> Subject: Re: Index optimization ...
>>
>> Why do you run an optimize every 4 hours?
>>
>>
>> --
>> Ian.
>>
>>
>> On Wed, Jul 30, 2008 at 2:46 PM, Dragon Fly &l
re the inactive copy is made active.
> Date: Wed, 30 Jul 2008 14:54:03 +0100
> From: [EMAIL PROTECTED]
> To: java-user@lucene.apache.org
> Subject: Re: Index optimization ...
>
> Why do you run an optimize every 4 hours?
>
>
> --
> Ian.
>
>
> On Wed, Ju
ctor, would it make the indexing slower
> (which I'm OK with) but the optimization faster? Thank you.
>
>> Date: Tue, 29 Jul 2008 08:32:46 +0200
>> From: [EMAIL PROTECTED]
>> To: java-user@lucene.apache.org
>> Subject: Re: Index optimization ...
>>
>>
PROTECTED]
> To: java-user@lucene.apache.org
> Subject: Re: Index optimization ...
>
> John Griffin:
> > Use IndexWriter.setRAMBufferSizeMB(double mb) and you won't have to
> > sacrifice anything. It defaults to 16.0 MB so depending on the size of your
> > ind
John Griffin:
> Use IndexWriter.setRAMBufferSizeMB(double mb) and you won't have to
> sacrifice anything. It defaults to 16.0 MB so depending on the size of your
> index you may want to make it larger. Do some testing at various values to
> see where the sweet spot is.
>
Also, have a look at
htt
Try IndexWriter.optimize(int maxNumSegments)
On Mon, Jul 28, 2008 at 11:30 PM, Dragon Fly <[EMAIL PROTECTED]>wrote:
> I'd like to shorten the time it takes to optimize my index and am willing
> to sacrifice search and indexing performance. Which parameters (e.g. merge
> factor) should I change?
ragon Fly [mailto:[EMAIL PROTECTED]
Sent: Monday, July 28, 2008 12:00 PM
To: java-user@lucene.apache.org
Subject: Index optimization ...
I'd like to shorten the time it takes to optimize my index and am willing to
sacrifice search and indexing performance. Which parameters (e.g. merge
factor
I'd like to shorten the time it takes to optimize my index and am willing to
sacrifice search and indexing performance. Which parameters (e.g. merge
factor) should I change? Thank you.
_
Stay in touch when you're away with Windows
files in
it? What I do now is delete it manually. Is there by any chance that I can
delete it automatically? Any code that I can refer to?
--
View this message in context:
http://www.nabble.com/Index-Optimization-Issue-tp15996864p15996864.html
Sent from the Lucene - Java Users mailing list archi
That works, thanks.
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Yonik Seeley
Sent: Tuesday, June 19, 2007 9:57 AM
To: java-user@lucene.apache.org
Subject: Re: MultiSearcher holds on to index - optimization not one segment
On 6/19/07, Beard, Brian
On 6/19/07, Beard, Brian <[EMAIL PROTECTED]> wrote:
This may seem like a naïve question - since the garbage collection is not
enforcable, is it possible to send a flag to the IndexReader to give this up
once the reader is no longer needed?
You call close() on the IndexReader (or the IndexSear
: Tuesday, June 19, 2007 9:06 AM
To: java-user@lucene.apache.org
Subject: Re: MultiSearcher holds on to index - optimization not one segment
On 6/19/07, Beard, Brian <[EMAIL PROTECTED]> wrote:
> The problem I'm having is once the MultiSearcher is open, it holds on to
> t
On 6/19/07, Beard, Brian <[EMAIL PROTECTED]> wrote:
The problem I'm having is once the MultiSearcher is open, it holds on to
the index file
An IndexReader holds open the files... this is a feature. Not holding
the file open would mean that the index would actively change while
being searched.
We're using a MultiSearcher to search against multiple lucene indexes
which runs inside of a web application in jboss 4.0.4.
We're also using a standalone app running in a different jboss server
which gets periodic updates from an oracle database and updates the
lucene index.
Both the searcher a
missing something?
Regards,
Stanislav
Mike Klaas wrote:
On 10/27/06, Stanislav Jordanov <[EMAIL PROTECTED]> wrote:
Have the following problem with (explicitly invoked) index
optimization -
it seems to always merge all existing index segments into a single huge
segment, which is undesirable
On 10/27/06, Stanislav Jordanov <[EMAIL PROTECTED]> wrote:
Have the following problem with (explicitly invoked) index optimization -
it seems to always merge all existing index segments into a single huge
segment, which is undesirable in my case.
Is there a way to force index optimizat
[Note: I am reposting this question, as I posted it yesterday and yet it
hasn't appear on the mail list]
Have the following problem with (explicitly invoked) index optimization -
it seems to always merge all existing index segments into a single huge
segment, which is undesirable in my
Have the following problem with (explicitly invoked) index optimization -
it seems to always merge all existing index segments into a single huge
segment, which is undesirable in my case.
Is there a way to force index optimization to honor the
IndexWriter.MAX_MERGE_DOCS setting?
Stanislav
26 matches
Mail list logo