On 3/4/2016 5:46 AM, Cool Techi wrote: > We are using solr 4.8.1 cloud and have a single shard core and 3 replicas in > total. We are noticing the following issues, > 1) Master propagates slow to to the other nodes/replicas.2) This increase > over a period of time, i.e the data propagation time increase as the time > from which leader is elected increases? > What could be causing this, our commit settings are given below. > <autoCommit> > <maxTime>12000</maxTime> > <maxDocs>25000</maxDocs> > <openSearcher>false</openSearcher> > </autoCommit> > > <!-- softAutoCommit is like autoCommit except it causes a > 'soft' commit which only ensures that changes are visible > but does not ensure that data is synced to disk. This is > faster and more near-realtime friendly than a hard commit. > --> > <autoSoftCommit> > <maxTime>1000</maxTime> > </autoSoftCommit>
There's very little information to go on here. This information will help troubleshoot performance problems: * How many Solr instances are running? * How many machines are running those Solr instances? * What is the max heap setting on each of those instances? * Are you running with the included jetty (start.jar) or a separate container? * How big is each replica in terms of disk space? * How many documents are in each replica? * How much memory is installed in each machine? * How frequently are you sending updates, and how many updates per batch? * How long is Solr taking to do commits that open a new searcher? * What is your query rate? An autoSoftCommit value of one second is a major source of performance problems. A commit that opens a new Searcher (which soft commits do) will usually take longer than one second to occur. http://lucidworks.com/blog/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/ The first thing I would try is increasing the maxTime on both autoCommit and autoSoftCommit. I would use five minutes for autoCommit. For autoSoftCommit, I wouldn't go lower than one minute, and a value of five to 15 minutes would be better. Thanks, Shawn