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