Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: domain of nigelspleen@gmail.com
 designates 209.85.218.222 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=i5JGioK03iPvl8ci+a2f45OFMUWpQokdaJNsVH63J8GJECY7nAxXjr9ctfbjv9nXuZ
         59/OETWQkeFantNpVfkHraqLTvCng3thTmX128NrmLQwTIusva+h8Ypl18UCHiRC6Wn5
         O7lm8BKg74Z5U6qirZrMh5N9DEeiqeFjXCot4=
MIME-Version: 1.0
In-Reply-To: <5A007EE2ACD1449297B14DEB2CE02C9B@VEGA>
References: <843920a30906231353n6021c4bcl4fa7d14512c5f1b2@mail.gmail.com>
	 <p06240809c6670270c70a@192.168.1.43>
	 <5A007EE2ACD1449297B14DEB2CE02C9B@VEGA>
Date: Wed, 24 Jun 2009 14:54:03 -0400
Message-ID: <843920a30906241154m66f477f1n970aad5cc75e6371@mail.gmail.com>
Subject: Re: Analyzing performance and memory consumption for boolean queries
From: Nigel <nigelspleen@gmail.com>
To: java-user@lucene.apache.org
Content-Type: multipart/alternative; boundary=001636c924d9875d3b046d1ca1c4

--001636c924d9875d3b046d1ca1c4
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Hi Uwe,

Good points, thank you.  The obvious place where GC really has to work hard
is when index changes are rsync'd over and we have to open the new index and
close the old one.  Our slow performance times don't seem to be directly
correlated with the index rotation, but maybe it just appears that way,
since it may take a little while before GC kicks in to try to recover the
objects used by the closed index.

Chris

On Wed, Jun 24, 2009 at 3:33 AM, Uwe Schindler <uwe@thetaphi.de> wrote:

> I had similar problems with our configuration, too. Suddenly sometimes the
> server even did not respond. The problem was (I think is the same here):
> the
> GC. The standard Java GC is not multithreaded, so if you have lots of
> traffic at some time, the JVM halts all threads and starts to GC, which can
> take very long time with so big heap sizes.
>
> On our server with indexes of similar disk space size (not documents), I
> changed the JVM options to use:
>
> -Xms4096M -Xmx8192M -XX:MaxPermSize=512M -Xrs -XX:+UseConcMarkSweepGC
> -XX:+UseParNewGC -verbosegc -XX:+PrintGCDetails -XX:+UseLargePages
>
>

--001636c924d9875d3b046d1ca1c4--