lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gili Nachum <gilinac...@gmail.com>
Subject Re: 43sec commit duration - blocked by index merge events?
Date Fri, 13 Feb 2015 13:50:53 GMT
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.gospodnetic@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 <gilinachum@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.
> >
>

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