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 <[email protected]> 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 < > [email protected]> 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 <[email protected]> > 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. > > > > > >
