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. >
