From dev-return-101910-apmail-lucene-dev-archive=lucene.apache.org@lucene.apache.org Sun Jul 1 03:57:21 2012 Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 8694F9E8D for ; Sun, 1 Jul 2012 03:57:21 +0000 (UTC) Received: (qmail 25430 invoked by uid 500); 1 Jul 2012 03:57:20 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 25283 invoked by uid 500); 1 Jul 2012 03:57:20 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 25262 invoked by uid 99); 1 Jul 2012 03:57:19 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Jul 2012 03:57:19 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.220.101.25] (HELO wunderwood.org) (192.220.101.25) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 01 Jul 2012 03:57:12 +0000 Received: (qmail 9637 invoked by uid 25881); 1 Jul 2012 03:56:51 -0000 Received: from unknown (HELO [192.168.1.70]) (wunder@[76.218.106.138]) (envelope-sender ) by 192.220.101.25 (qmail-ldap-1.03) with AES128-SHA encrypted SMTP for ; 1 Jul 2012 03:56:51 -0000 Subject: Re: Low pause GC for java 1.6 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_29A55783-038F-4136-943F-CFA21BF10294" From: Walter Underwood In-Reply-To: <5F2CAA1D-877A-46D4-B8B6-91D6E8CE7A07@gmail.com> Date: Sat, 30 Jun 2012 20:56:49 -0700 Cc: Bill Bell Message-Id: <4530EB86-BB84-41B0-8279-1AEA55752367@wunderwood.org> References: <5F2CAA1D-877A-46D4-B8B6-91D6E8CE7A07@gmail.com> To: dev@lucene.apache.org X-Mailer: Apple Mail (2.1278) X-Virus-Checked: Checked by ClamAV on apache.org --Apple-Mail=_29A55783-038F-4136-943F-CFA21BF10294 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Is that a 4 second or 0.4 second wait? You can benchmark the different collectors yourself. CMS is probably the best choice.=20 If you have more heap than you need, then the collections will be longer = than necessary. At some point, the collector has to look at all of the = heap and that is slow. Try reducing the heap size. You really should use a tool that graphs the GC behavior. Make sure that = you have a big enough nursery (or whatever Sun calls it) to handle all = of the temporary storage for for each HTTP request. You want all of that = to be reclaimed in the minor collections. If per-request storage is = allocated in tenured space, that means the next major GC will be sooner = than necessary. wunder On Jun 30, 2012, at 6:48 PM, Bill Bell wrote: > Nothing? >=20 > Bill Bell > Sent from mobile >=20 >=20 > On Jun 29, 2012, at 9:09 PM, Bill Bell wrote: >=20 >> We are getting large Solr pauses on Java garbage collection in 1.6 = Java. >>=20 >> We have tried CMS. But we still have. 4 second wait on GC. >>=20 >> What works well for Solr when using 16 GB of RAM? >>=20 >> I have read lots of articles and now just looking for practical = advise and examples. >>=20 >> Sent from my Mobile device >> 720-256-8076 >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: dev-help@lucene.apache.org >=20 --Apple-Mail=_29A55783-038F-4136-943F-CFA21BF10294 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Is = that a 4 second or 0.4 second wait?

You can benchmark = the different collectors yourself.

CMS is = probably the best choice. 

If you have = more heap than you need, then the collections will be longer than = necessary. At some point, the collector has to look at all of the heap = and that is slow. Try reducing the heap = size.

You really should use a tool that graphs = the GC behavior. Make sure that you have a big enough nursery (or = whatever Sun calls it) to handle all of the temporary storage for for = each HTTP request. You want all of that to be reclaimed in the minor = collections. If per-request storage is allocated in tenured space, that = means the next major GC will be sooner than = necessary.

wunder

On = Jun 30, 2012, at 6:48 PM, Bill Bell wrote:

Nothing?

Bill Bell
Sent from = mobile


On Jun 29, 2012, at 9:09 PM, Bill Bell <billnbell@gmail.com> = wrote:

We are getting large Solr pauses = on Java garbage collection in 1.6 Java.

We have tried = CMS. But we still have. 4 second wait on GC.

What works well = for Solr when using 16 GB of RAM?

I have read = lots of articles and now just looking for practical advise and = examples.

Sent from my = Mobile device
720-256-8076

---------------------------= ------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.a= pache.org
For additional commands, e-mail: dev-help@lucene.apache.org<= br>

= --Apple-Mail=_29A55783-038F-4136-943F-CFA21BF10294--