Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of pid@pidster.com designates
 209.85.215.182 as permitted sender)
References: 
 <CAMnZpZfexRAeF4UwGRwpPaSUZY=3P4Om=bVHZOgshw9JDSnXRg@mail.gmail.com>
 <5230540501921740190@unknownmsgid>
 <CAMnZpZfRU7c4Ad_p9Mp-dQHWJ+vUHHrYdRCkDjrkD+0UN+J6bQ@mail.gmail.com>
 <516D1A19.5090608@ice-sa.com>
 <CAMnZpZcHuOquaQZx+hcJ7FK3Y9ioLSqY5FWUmiWuKgFQJ9aE=Q@mail.gmail.com>
 <516DA96D.2060407@christopherschultz.net>
From: =?UTF-8?B?UMOvZCBzdMOocg==?= <pid@pidster.com>
In-Reply-To: <516DA96D.2060407@christopherschultz.net>
Mime-Version: 1.0 (1.0)
Date: Tue, 16 Apr 2013 21:54:48 +0100
Message-ID: <-7116370485504284132@unknownmsgid>
Subject: Re: ParNew promotion failed in verbose GC logs
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: text/plain; charset=UTF-8

On 16 Apr 2013, at 20:42, Christopher Schultz
<chris@christopherschultz.net> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Vidyadhar,
>
> On 4/16/13 1:14 PM, Techienote com wrote:
>> With default setting we were getting frequent OOM errors. After
>> analyzing the heap dump we found
>> org.apache.poi.hssf.usermodel.HSSFSheet is accumulating more heap
>> memory. As per the application development this is the normal
>> behavior and have suggested to increase the maximum heap size to
>> 2048MB
>
> So, you keep lots of spreadsheets in memory for some reason? I can't
> imagine that loading a Microsoft Excel document into memory and
> keeping it in what POI calls "horrible spreadsheet format" is the best
> way to keep that information around. I suppose only /you/ know you
> requirements.
>
> Just how many spreadsheets do you need to keep in memory?
>
>> After increasing the max heap size we were seeing some large GC
>> pauses for the same we tried to change the JVM policy to CMS and
>> added following parameters
>>
>> -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
>> -XX:+CMSParallelRemarkEnabled
>
> Did you enable verbose GC logging before/after you enabled those
> options? Did it help anything? Do you have any idea *why* your GCs
> were taking so long, or did you just Google for "java gc is taking a
> long time" and enable those options because they were "recommended" by
> someone?
>
>> Since then the long pauses reduced from 112 seconds to 90 seconds.
>
> Without seeing your data, I would guess that it's only a coincidence
> that your pauses have decreased in duration: you have likely not had
> any improvement by changing the GC configuration.
>
>> Also we have seeing regular permanent generation concurrent mark
>> failure which got reduced after changing NewSize to 512MB.
>
> Well, the NewSize shouldn't have any bearing on anything happening in
> PermGen, other than maybe allowing OutOfMemoryErrors to occur if you
> overfill PermGen. But that's not happening, here.

+1

Did CMS in 1.5 actually collect in PermGen? (Genuinely don't know the
answer to that)


p


>
>> -Dsun.rmi.dgc.client.gcInterval=3600000
>> -Dsun.rmi.dgc.server.gcInterval=3600000 -XX:+DisableExplicitGC
>
> If I understand correctly (and I don't claim to be a GC ergonomics
> expert), those options are mutually-exclusive. Disabling explicit GC
> should disable the RMI's use of .. explicit garbage-collection. So, if
> you really are using RMI, disabling explicit garbage-collection can
> ruin everything. [See
> http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html#1.1.Other%20Considerations|outline].
>
> Have you tried with a supported version of a Java VM?
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
> Comment: GPGTools - http://gpgtools.org
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iQIcBAEBCAAGBQJRbalsAAoJEBzwKT+lPKRY1/kP/isK8UjCkC3PB1WCgSp9aDNI
> iOomoVHiXlL/0m4YTp/mxveB+8rs5edxrJPSeWJkpJAEs/4MU3MXVflapC2a90ij
> FhcXd0QvR1Cf0KE97wWiwXWRTtn60wOErutvOqZ9/HnaVwWRBZhczlJ+ZEwQ9ms1
> vcFQMFsoOVFpFQT1rh4T+1ruRO+qorT1ybl7gkIPXNb4mkdgqrxkCiSwI2eB0w/p
> b2Ig1ugx9wNB9petyfhVpOffl7jbl/18KdJXj5N1hKQ2tAfzOCSf6nTNeFluG+zd
> J9/Wa6nOePgGf8+OzeIbvHS96u4SBOYt3NR1d/Vz1eIk1dvAxkp5aiBTvtv3l+Js
> /TogUoHSjXILfH+zzutvoucHCFcAOtDD4O658z/BcfROnRBpz6TYoEhtGob3d+Zp
> TFDM3N3WUt+566pKwNQtJfrOGJjq5IM7iBZKeofDiZGmJ1FiL89gdCWuHNpzvCX8
> sV8xuwBVEWXQwz+VuLW2FB9PaTSOUBqOMBjbt3sjjuY7Uw6lMEszDhXP7nAhlYEj
> EsF9uXoWZBWMJZF+1p9KhjD3qNBhTKgB21TSzq59Mjw7FvhZE5pKDOqhYP/uyxi8
> nigqrjKJbKATBztpOiR8bjvb+LSJy0hvf6bNhvAZY6S4qRU6K2kWkFfPz3v6QIiz
> GmxHvSCPXNHhx+X7S+3t
> =YmSW
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org