Are you using solr 4.0? We had some problems similar to this (not in a
master/slave setup, though), where the resolution was to disable the
transaction log, i.e. remove <updateLog> in the <updateHandler> section -
we don't need NRT get, so this isn't important to us.

Cheers,
/Martin Koch

On Thu, Nov 1, 2012 at 1:25 AM, dbabits <dbab...@gmail.com> wrote:

> I second the original poster- all selects are blocked during commits.
> I have Master replicating to Slave.
> Indexing happens to Master, few docs/about every 30 secs
> Selects are run against Slave.
>
> This is the pattern from the Slave log:
>
> Oct 30, 2012 12:33:23 AM org.apache.solr.core.SolrDeletionPolicy
> updateCommits
> INFO: newest commit = 1349195567630
> Oct 30, 2012 12:33:42 AM org.apache.solr.core.SolrCore execute
> INFO: [core3] webapp=/solr path=/select
>
> During the 19 seconds that you see between the 2 lines, the /select is
> blocked, until the commit is done.
> This has nothing to do with jvm, I'm monitoring the memory and GC stats
> with
> jConsole and log.
> I played with all settings imaginable: commitWithin, commit=true,
> useColdSearcher, autoWarming settings from 0 on-nothing helps.
>
> The environment is: 3.6.0, RHEL Lunux 5.3.2, 64-bit, 96G RAM, 6 CPU cores,
> java 1.6.0_24, ~70 million docs.
> As soon as I suspend replication (command=disablepoll), everything becomes
> fast.
> As soon as I enable it - it pretty much becomes useless.
> Querying Master directly exibits the same problem of course.
>
> Thanks a lot for your help.
>
>
>
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/solr-blocking-on-commit-tp474874p4017416.html
> Sent from the Solr - User mailing list archive at Nabble.com.
>

Reply via email to