|
|
Have you tried out, if GC affects you? A first step would be to turn on GC
logging with -verbosegc -XX:+PrintGCDetails
If you see some relation between query time and gc messages, you should try
to use a better parallelized GC and change the perm size and so on (se docs
about GC tuning).
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: uwe@xxxxxxxxxxx
> -----Original Message-----
> From: Nigel [mailto:nigelspleen@xxxxxxxxx]
> Sent: Wednesday, June 24, 2009 8:54 PM
> To: java-user@xxxxxxxxxxxxxxxxx
> Subject: Re: Analyzing performance and memory consumption for boolean
> queries
>
> 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@xxxxxxxxxxx> 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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: java-user-help@xxxxxxxxxxxxxxxxx
|
|