Return-Path: Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org Received: (qmail 48774 invoked from network); 9 Aug 2009 21:31:09 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 9 Aug 2009 21:31:09 -0000 Received: (qmail 43046 invoked by uid 500); 9 Aug 2009 21:31:16 -0000 Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org Received: (qmail 42967 invoked by uid 500); 9 Aug 2009 21:31:16 -0000 Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-dev@lucene.apache.org Delivered-To: mailing list solr-dev@lucene.apache.org Received: (qmail 42957 invoked by uid 99); 9 Aug 2009 21:31:16 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 09 Aug 2009 21:31:16 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jimmoefoe@gmail.com designates 209.85.212.191 as permitted sender) Received: from [209.85.212.191] (HELO mail-vw0-f191.google.com) (209.85.212.191) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 09 Aug 2009 21:31:06 +0000 Received: by vws29 with SMTP id 29so2429727vws.20 for ; Sun, 09 Aug 2009 14:30:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=97H5TXyxEr5c+54ohPWI2eNSfqpMLf+33ype1RG7N3g=; b=Zs16tust97bboq13VK0FddfRQ2Xx0CNHCzLZF9Rg+yvDZCZSx3E297UurRpo8dqlE/ bwcOTkSQWsVhkFZ00fqHkDgPkakBF1kmDzOgClNefdKWOiLL3PbAnb2WxpZSM5HwdFyu plZ8t9S4snN9qgV5e1tP9iG3MtqkB5CB05yso= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=hWo286fH9sZ3GhqOSLKPBLyEtwASTb9wGloPOcMgdaDcjZomuMiO0yj3jjrUmvzUvg c8yKbJyyVhwud96fisTeXs0msXSBXcOJ2XWEhjgXryCDJDdyHjjbY8CcTz4kkrjMhDEw 6TYcxadmDOhrkywZL0lhtFOTVw+HQIzM+Klzs= MIME-Version: 1.0 Received: by 10.220.70.147 with SMTP id d19mr3739506vcj.107.1249853445616; Sun, 09 Aug 2009 14:30:45 -0700 (PDT) Date: Sun, 9 Aug 2009 14:30:45 -0700 Message-ID: <142154980908091430u6ceb7e88k66f79de8c909906a@mail.gmail.com> Subject: Severe QTime issues to do with updates From: Kaktu Chakarabati To: solr-dev@lucene.apache.org Content-Type: multipart/alternative; boundary=0016e6475ae8a5b62e0470bc2e5e X-Virus-Checked: Checked by ClamAV on apache.org --0016e6475ae8a5b62e0470bc2e5e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hey, I've recently noticed that there is a very large spike in the QTime for nodes serving queries, immediately after snappulling and snapinstalling. The numbers i'm seeing there are obviously some kind of lock-contention/concurrency issue, as I've monitored iostat/sar and its not a disk IO issue ( all the index is still mostly in the os caches, as is also noticeable in the snappuller.log which runs very fast - the incremental update to the lucene index is minimal). I'm using a strong machine (16GB 2xQuadCore, CentOS5) for this and from all monitoring the CPU/Disk IO seems minimal through-out the day. The update runs every 10 minutes, takes about 200seconds to complete (with my current autoWarm settings)., and the index size is about 20million documents (~6GB). queries/warmup involve mostly some pre-fixed set of filters and facets. I'm using a nightly build of solr from few months back ( nightly exported - yonik - 2009-01-11 08:05:52 ) which should already have the benefits of readonlyindexreader, NIOFS, UnInvertedIndex and ConcurrentLRUCache (for filterCache). I've read a related thread a guy called oleg posted ( http://mail-archives.apache.org/mod_mbox/lucene-solr-user/200901.mbox/%3C339777.57289.qm@web50307.mail.re2.yahoo.com%3E) , but did not see the thread concluded with any definite conclusion. Please advise! Best regards, -Chak --0016e6475ae8a5b62e0470bc2e5e--