Hi,
Smaller merge factor will make things worse - it will cause Lucene to merge
index segments more often (than the default merge factor of 10), thus resulting
in more new files being created on the master, thus resulting in more network
IO, more disk IO on the slaves, more OS cache evicted on the slaves, longer
warmup times on slaves, higher CPU usage and higher query latency on slaves
during warmup. The sequence to remember.
Otis
----
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch
Lucene ecosystem search :: http://search-lucene.com/
----- Original Message ----
> From: Blargy <zman...@hotmail.com>
> To: solr-user@lucene.apache.org
> Sent: Fri, June 18, 2010 12:41:32 AM
> Subject: Re: Peformance tuning
>
>
Blargy - Please try to quote the mail you're responding to, at
> least
> the relevant piece. It's nice to see some context to
> the discussion.
No problem ;)
Depends - if you optimize the
> index on the master, then the entire index is
replicated. If you simply
> commit and let Lucene take care of adding
segments you'll generally
> reduce what is replicated.
As a side question... would reducing the
> mergeFactor help at all? This is
currently what I am
> using...
<mainIndex>
> <useCompoundFile>false</useCompoundFile>
> <ramBufferSizeMB>64</ramBufferSizeMB>
> <mergeFactor>5</mergeFactor>
> <unlockOnStartup>false</unlockOnStartup>
> <reopenReaders>true</reopenReaders>
> <deletionPolicy class="solr.SolrDeletionPolicy">
> <str name="maxCommitsToKeep">1</str>
<str
> name="maxOptimizedCommitsToKeep">0</str>
> </deletionPolicy>
<infoStream
> file="INFOSTREAM.txt">false</infoStream>
> </mainIndex>
--
View this message in context:
> href="http://lucene.472066.n3.nabble.com/Peformance-tuning-tp904540p904810.html";
>
> target=_blank
> >http://lucene.472066.n3.nabble.com/Peformance-tuning-tp904540p904810.html
Sent
> from the Solr - User mailing list archive at Nabble.com.
