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: u...@thetaphi.de > -----Original Message----- > From: Nigel [mailto:nigelspl...@gmail.com] > Sent: Wednesday, June 24, 2009 8:54 PM > To: java-user@lucene.apache.org > 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 <u...@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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
