One technique to control commit times is to do automatic commits: you can configure a core to commit every N seconds (really milliseconds, but less than 5 minutes becomes difficult) and/or every N documents. This promotes a more fixed amount of work per commit.
Also, the maxMergeDocs parameter lets you force a maximum segment size (in documents). This may cap the longest possible commit times. http://www.lucidimagination.com/search/document/CDRG_ch08_8.1.2.3?q=maxMergeDocs On Fri, Mar 5, 2010 at 2:57 PM, Otis Gospodnetic <otis_gospodne...@yahoo.com> wrote: > Jerry, > > This is why people often do index modifications on one server (master) and > replicate the read-only index to 1+ different servers (slaves). > If you do that, does the problem go away? > > Otis > ---- > Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch > Hadoop ecosystem search :: http://search-hadoop.com/ > > > > ----- Original Message ---- >> From: Jerome L Quinn <jlqu...@us.ibm.com> >> To: solr-user@lucene.apache.org >> Sent: Fri, March 5, 2010 10:13:03 AM >> Subject: Re: SolrJ commit options >> >> Shalin Shekhar Mangar wrote on 02/25/2010 07:38:39 >> AM: >> >> > On Thu, Feb 25, 2010 at 5:34 PM, gunjan_versata >> wrote: >> > >> > > >> > > We are using SolrJ to handle commits to our solr server.. All runs >> fine.. >> > > But whenever the commit happens, the server becomes slow and stops >> > > responding.. therby resulting in TimeOut errors on our production. We >> are >> > > using the default commit with waitFlush = true, waitSearcher = true... >> > > >> > > Can I change there values so that the requests coming to solr dont >> block on >> > > recent commit?? Also, what will be the impact of changing these >> values?? >> > > >> > >> > Solr does not block reads during a commit/optimize. Write operations are >> > queued up but they are still accepted. Are you using the same Solr server >> > for reads as well as writes? >> >> I've seen similar things with Solr 1.3 (not using SolrJ). If I try to >> optimize the >> index, queries will take much longer - easily a minute or more, resulting >> in timeouts. >> >> Jerry > > -- Lance Norskog goks...@gmail.com
