Return-Path: Delivered-To: apmail-lucene-solr-user-archive@locus.apache.org Received: (qmail 49082 invoked from network); 22 Jan 2009 20:01:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Jan 2009 20:01:26 -0000 Received: (qmail 44759 invoked by uid 500); 22 Jan 2009 20:01:22 -0000 Delivered-To: apmail-lucene-solr-user-archive@lucene.apache.org Received: (qmail 44729 invoked by uid 500); 22 Jan 2009 20:01:22 -0000 Mailing-List: contact solr-user-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-user@lucene.apache.org Delivered-To: mailing list solr-user@lucene.apache.org Received: (qmail 44718 invoked by uid 99); 22 Jan 2009 20:01:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Jan 2009 12:01:22 -0800 X-ASF-Spam-Status: No, hits=2.6 required=10.0 tests=DNS_FROM_OPENWHOIS,SPF_HELO_PASS,SPF_PASS,WHOIS_MYPRIVREG X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of lists@nabble.com designates 216.139.236.158 as permitted sender) Received: from [216.139.236.158] (HELO kuber.nabble.com) (216.139.236.158) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 22 Jan 2009 20:01:14 +0000 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1LQ5jR-0006Va-EJ for solr-user@lucene.apache.org; Thu, 22 Jan 2009 12:00:53 -0800 Message-ID: <21611976.post@talk.nabble.com> Date: Thu, 22 Jan 2009 12:00:53 -0800 (PST) From: oleg_gnatovskiy To: solr-user@lucene.apache.org Subject: Re: Query Performance while updating teh index In-Reply-To: <34128.62548.qm@web50310.mail.re2.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Nabble-From: oleg_gnatovskiy@citysearch.com References: <20452835.post@talk.nabble.com> <20467099.post@talk.nabble.com> <20968516.post@talk.nabble.com> <574630.55488.qm@web50303.mail.re2.yahoo.com> <20980523.post@talk.nabble.com> <20980669.post@talk.nabble.com> <8599F2E4E80ECC44AEE81FA2974CE2BD0C31C942@mail-sd1.ad.soe.sony.com> <21573927.post@talk.nabble.com> <485478.37082.qm@web50307.mail.re2.yahoo.com> <21611642.post@talk.nabble.com> <34128.62548.qm@web50310.mail.re2.yahoo.com> X-Virus-Checked: Checked by ClamAV on apache.org We've tried it. There doesn't seem to be any connection between GC and the bad performance spikes. Otis Gospodnetic wrote: > > OK. Then it's likely not this. You saw the other response about looking > at GC to see if maybe that hits you once in a while and slows whatever > queries are in flight? Try jconsole. > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > ----- Original Message ---- >> From: oleg_gnatovskiy >> To: solr-user@lucene.apache.org >> Sent: Thursday, January 22, 2009 2:43:31 PM >> Subject: Re: Query Performance while updating teh index >> >> >> We do optimize the index before updates but we get tehse performance >> issues >> even when we pull an empty snapshot. Thus even when our update is tiny, >> the >> performance issues still happen. >> >> >> >> Otis Gospodnetic wrote: >> > >> > This is an old and long thread, and I no longer recall what the >> specific >> > suggestions were. >> > My guess is this has to do with the OS cache of your index files. When >> > you make the large index update, that OS cache is useless (old files >> are >> > gone, new ones are in) and the OS cache has get re-warmed and this >> takes >> > time. >> > >> > Are you optimizing your index before the update? Do you *really* need >> to >> > do that? >> > How large is your update, what makes it big, and could you make it >> > smaller? >> > >> > Otis >> > -- >> > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch >> > >> > >> > >> > ----- Original Message ---- >> >> From: oleg_gnatovskiy >> >> To: solr-user@lucene.apache.org >> >> Sent: Tuesday, January 20, 2009 6:19:46 PM >> >> Subject: Re: Query Performance while updating teh index >> >> >> >> >> >> Hello again. It seems that we are still having these problems. Queries >> >> take >> >> as long as 20 minutes to get back to their average response time after >> a >> >> large index update, so it doesn't seem like the problem is the 12 >> second >> >> autowarm time. Are there any more suggestions for things we can try? >> >> Taking >> >> our servers out of teh loop for as long as 20 minutes is a bit of a >> >> hassle, >> >> and a risk. >> >> -- >> >> View this message in context: >> >> >> http://www.nabble.com/Query-Performance-while-updating-the-index-tp20452835p21573927.html >> >> Sent from the Solr - User mailing list archive at Nabble.com. >> > >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Query-Performance-while-updating-the-index-tp20452835p21611642.html >> Sent from the Solr - User mailing list archive at Nabble.com. > > > -- View this message in context: http://www.nabble.com/Query-Performance-while-updating-the-index-tp20452835p21611976.html Sent from the Solr - User mailing list archive at Nabble.com.