lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otis Gospodnetic <>
Subject Re: 43sec commit duration - blocked by index merge events?
Date Thu, 12 Feb 2015 18:46:45 GMT
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.


Monitoring * Alerting * Anomaly Detection * Centralized Log Management
Solr & Elasticsearch Support *

On Sun, Feb 8, 2015 at 6:48 AM, Gili Nachum <> 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
> <
> >
> 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.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message