worry about segment sizes and merge
policies. That comes later.
On Mon, Nov 25, 2013 at 11:48 AM, Desidero wrote:
> Providing your system specs, parallelism (# of writer threads in a
> specific example), and any other special values you set (RAMBufferSizeMB,
> maxThreadStates, etc) would
Providing your system specs, parallelism (# of writer threads in a
specific example), and any other special values you set (RAMBufferSizeMB,
maxThreadStates, etc) would be helpful.
--
I do most of my development on a 64 core machine. When doing a full
reindex, I have 64 worker threads doing conc
I've never had to do that, but a quick Google search brought this up:
http://stackoverflow.com/questions/9935177/how-to-repair-corrupted-lucene-index
Another (possibly better and definitely safer) solution would be to log
your updates in a way that would allow you to reprocess them in sequence.
It
sent a concrete side by side
> comparison. Also, from your description, what you are doing to
> extend/replace internal plumbing in IndexSearcher sounds awfully complex
> and hard to envision... do make sure to run functional tests when it's all
> in place. :)
>
>
> On
nce to
> IndexSearcher.
>
> A strategy like that should provide for better query throughput, regardless
> of whether each shard consists of a single segment or not - provided each
> of the queries is tied to a particular shard and can't search any others.
>
>
>
ying with it tonight, but in the meantime I don't
suppose anyone else knows a way to accomplish what I'm trying to do without
using forceMerge(1)?
On Tue, Oct 1, 2013 at 6:10 PM, Desidero wrote:
> Uwe,
>
> I was using a bounded thread pool.
>
> I don't know if the pr
o find out for sure.
Matt
Hi,
use a bounded thread pool.
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Desidero [mailto:desid...@gmail.com]
> Sent: Tuesday, October 01, 2013 11:37
27;m going to try to implement the "virtual segment" concept that Mike
mentioned. It'll be really helpful for those of us who want parallelism
within queries and don't want to forceMerge.
On Fri, Sep 27, 2013 at 9:55 AM, Desidero wrote:
> Erick,
>
> Thank you for respond
Benson,
Rather than forcing a random number of small segments into the index using
maxMergedSegmentMB, it might be better to split your index into multiple
shards. You can create a specific number of balanced shards to control the
parallelism and then forceMerge each shard down to 1 segment to avo
oad any fields?
>
> FWIW,
> Erick
>
> On Thu, Sep 26, 2013 at 10:55 AM, Desidero wrote:
> > A quick update:
> >
> > In order to confirm that none of the standard migration changes had a
> > negative effect on performance, I ported my Lucene
A quick update:
In order to confirm that none of the standard migration changes had a
negative effect on performance, I ported my Lucene 4.x version back to
Lucene 3.6.2 and kept the newer API rather than using the custom
ParallelMultiSearcher and other deprecated methods/classes.
Performance in
Hello,
Over the last few weeks I've been working on upgrading an application from
Lucene 3.x to Lucene 4.x in hopes of improving performance. Unfortunately,
after going through the full migration process and playing with all sorts
of tweaks I found online and in the documentation, Lucene 4 is runn
12 matches
Mail list logo
