I wasn't able to follow Otis' answer but... the purpose of commit is to make make recent document changes (since the last commit) visible to queries, and has nothing to do with merging of segments. IOW, take the new segment that is being created and not yet ready for use by query, and finish it so that query can access it. Soft commit vs. hard commit is simply a matter of whether Solr will wait for the I/O to write the new segment to disk to complete. Merging is an independent, background procedure (thread) that merges existing segments. It does seem odd that the cited doc does say that soft commit waits for background merges! (Hoss??)
-- Jack Krupansky On Fri, Feb 13, 2015 at 4:47 PM, Otis Gospodnetic < otis.gospodne...@gmail.com> wrote: > Check > http://search-lucene.com/?q=commit+wait+block&fc_type=mail+_hash_+user > > e.g. http://search-lucene.com/m/QTPa7Sqx81 > > Otis > -- > Monitoring * Alerting * Anomaly Detection * Centralized Log Management > Solr & Elasticsearch Support * http://sematext.com/ > > > On Fri, Feb 13, 2015 at 8:50 AM, Gili Nachum <gilinac...@gmail.com> wrote: > > > Thanks Otis, can you confirm that a commit call will wait for merges to > > complete before returning? > > > > On Thu, Feb 12, 2015 at 8:46 PM, Otis Gospodnetic < > > otis.gospodne...@gmail.com> wrote: > > > > > If you are using Solr and SPM for Solr, you can check a report that > shows > > > the # of files in an index and the report that shows you the max > docs-num > > > docs delta. If you see the # of files drop during a commit, that's a > > > merge. If you see a big delta change, that's probably a merge, too. > > > > > > You could also jstack or kill -3 the JVM and see where it's spending > its > > > time to give you some ideas what's going on inside. > > > > > > HTH. > > > > > > Otis > > > -- > > > Monitoring * Alerting * Anomaly Detection * Centralized Log Management > > > Solr & Elasticsearch Support * http://sematext.com/ > > > > > > > > > On Sun, Feb 8, 2015 at 6:48 AM, Gili Nachum <gilinac...@gmail.com> > > wrote: > > > > > > > Hello, > > > > > > > > During a load test I noticed a commit that took 43 seconds to > complete > > > > (client hard complete). > > > > Is this to be expected? What's causing it? > > > > I have a pair of machines hosting a 128M docs collection (8 shards, > > > > replication factor=2). > > > > > > > > Could it be merges? In Lucene merges happen async of commit > statements, > > > but > > > > reading Solr's doc for Update Hanlder > > > > < > > > > > > > > > > https://cwiki.apache.org/confluence/display/solr/UpdateHandlers+in+SolrConfig > > > > > > > > > it sounds like hard commits do wait for merges to occur: *" The > > tradeoff > > > is > > > > that a soft commit gives you faster visibility because it's not > waiting > > > for > > > > background merges to finish."* > > > > Thanks. > > > > > > > > > >
