activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arjen van der Meijden <acmmail...@tweakers.net>
Subject Re: GC Overhead limit exceeded?
Date Tue, 20 Oct 2015 20:35:41 GMT
Afaik, in modern JVM versions, many of the 'old' recommendations may not
really apply anymore or even reduce performance. The book 'Java
Performance: The Definitive Guide' for instance has this statement on
heap sizing:

"1. The JVM will attempt to find a reasonable minimum and maximum heap
size based on the machine it is running on.
2. Unless the application needs a larger heap than the default, consider
tuning the performance goals of a GC algorithm (given in the next
chapter) rather than fine-tuning the heap size."

So basically; see how it works first without specifying any limit (so
not 1GB either) and/or fiddle with the goals rather than the size of the
heap. If you need a certain minimum heap, for instance to offer
sufficient space for the 'memory'-store of ActiveMQ, you should
obviously specify at least that.

-XX:+UseTLAB; is enabled by default, so specifying it won't do anything :)

-Xms2G and -Xmx2G; forcing the min and max to the same value is not a
necessity for modern JVM's, it will also force the JVM in making
(potentially) less than optimal allocations for the various areas in the
HEAP and disable automatic resizing. On the other hand, it allows the
JVM to skip the resizing process altogether, so it can gain a bit
performance because of that as well.

-XX:+UseConcMarkSweepGC; this GC-variant will reduce pause times, but on
the cost of more cpu (although that may be worth it) and a bit less
effective GC (compared to the parallel GC). If your application is
sensitive to those long pauzes (which may be noticable at both the
producer and consumer sides) selecting either CMS or G1 may indeed be a
good choice. For heaps below 4GB, CMS is expected to outperform G1
(although that statement doesn't say G1 will always outperform CMS for
heaps above 4GB).

Best regards,

Arjen

On 20-10-2015 21:51, Howard W. Smith, Jr. wrote:
> My recommendation (what i'm using for my java web app using latest Java 8
> version):
>
> -Xms2G
> -Xmx2G
> -XX:+UseTLAB
> -XX:+UseConcMarkSweepGC
> -XX:+CMSClassUnloadingEnabled
>
> I've seen it recommended to make min and max the same value for best GC,
> but feel free to google/confirm that. :)
>
>
>
> On Tue, Oct 20, 2015 at 3:25 PM, Kevin Burton <burton@spinn3r.com> wrote:
>
>> It depends on your app.  Keep increasing it until you don't get any more
>> errors.
>>
>> On Tue, Oct 20, 2015 at 10:28 AM, <barry.barnett@wellsfargo.com> wrote:
>>
>>> So just the max to 2048, leave the min as 1024?
>>>
>>> Regards,
>>>
>>> Barry
>>>
>>>
>>> -----Original Message-----
>>> From: Basmajian, Raffi [mailto:rbasmajian@ofiglobal.com]
>>> Sent: Tuesday, October 20, 2015 1:18 PM
>>> To: users@activemq.apache.org
>>> Subject: RE: GC Overhead limit exceeded?
>>>
>>> Max memory is only 1Gb? Not knowing anything about your use cases or
>>> volumes, 1Gb is low, try increasing to 2Gb, so how far that gets you.
>>>
>>> Btw, on Java 8, "PERM" settings related to PermGen memory space are
>>> ignored; that space was removed, replaced with Meta space, use
>>> -XX:MaxMetaspaceSize to configure it, but probably best to leave it
>>> default, which I believe is unlimited.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: barry.barnett@wellsfargo.com [mailto:barry.barnett@wellsfargo.com]
>>> Sent: Tuesday, October 20, 2015 12:29 PM
>>> To: users@activemq.apache.org
>>> Subject: RE: GC Overhead limit exceeded? [ EXTERNAL ]
>>>
>>> We are at jdk1.8.0_45.
>>>
>>> These are our current mem settings:
>>>
>>> export JAVA_MIN_MEM=1024M # Minimum memory for the JVM export
>>> JAVA_MAX_MEM=1024M # Maximum memory for the JVM export
>> JAVA_PERM_MEM=128M #
>>> Minimum perm memory for the JVM export JAVA_MAX_PERM_MEM=256M # Maximum
>>> memory for the JVM
>>>
>>> Any recommendations on the increase?
>>>
>>>
>>>
>>> Regards,
>>>
>>> Barry Barnett
>>> Enterprise Queuing Services | (QS4U) Open Queuing Services Wells Fargo
>>> Cell: 803-207-7452
>>>
>>>
>>> -----Original Message-----
>>> From: burtonator2011@gmail.com [mailto:burtonator2011@gmail.com] On
>>> Behalf Of Kevin Burton
>>> Sent: Tuesday, October 20, 2015 10:54 AM
>>> To: users@activemq.apache.org
>>> Subject: Re: GC Overhead limit exceeded?
>>>
>>> This is memory.
>>>
>>> Increase ActiveMQ memory .... if you still have the problem try upgrading
>>> to Java 8 as it's better with GC...
>>>
>>> On Tue, Oct 20, 2015 at 5:48 AM, <barry.barnett@wellsfargo.com> wrote:
>>>
>>>> We are receiving the following errors:  Any idea where I might look to
>>>> figure this one out?  I ran GC from JConsole already.  The disk space
>>>> on the persistent storage is fine as well.
>>>>
>>>> 20 Oct 2015 04:07:18,201 | ERROR | dClientAuth=true |
>> TransportConnector
>>>>              | 94 - org.apache.activemq.activemq-osgi - 5.11.1 | Could
>>>> not accept connection : java.lang.Exception:
>>>> java.lang.OutOfMemoryError: GC overhead limit exceeded
>>>>
>>>> 20 Oct 2015 04:07:15,443 | ERROR | v-5.4.1_1/deploy | fileinstall
>>>>             | 7 - org.apache.felix.fileinstall - 3.5.0 | In main loop,
>>>> we have serious troublejava.lang.OutOfMemoryError: GC overhead limit
>>>> exceeded
>>>>
>>>> 20 Oct 2015 04:06:46,876 | WARN  | roker] Scheduler | Topic
>>>>             | 94 - org.apache.activemq.activemq-osgi - 5.11.1 | Failed
>>>> to browse Topic: TOPIC_NAME
>>>> java.lang.OutOfMemoryError: GC overhead limit exceeded
>>>>
>>>> 20 Oct 2015 04:07:44,164 | ERROR | QUEUENAME] | RollbackTask
>>>>        | 105 - org.apache.aries.transaction.manager - 1.0.0 |
>>>> Unexpected exception committing
>>>> org.apache.geronimo.transaction.manager.WrapperNamedXAResource@198926b
>>>> f; continuing to commit other RMsjavax.transaction.xa.XAException: The
>>>> method 'xa_rollback' has failed with errorCode '-4'.
>>>>
>>>> Regards,
>>>>
>>>> Barry
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>> We’re hiring if you know of any awesome Java Devops or Linux Operations
>>> Engineers!
>>>
>>> Founder/CEO Spinn3r.com
>>> Location: *San Francisco, CA*
>>> blog: http://burtonator.wordpress.com
>>> … or check out my Google+ profile
>>> <https://plus.google.com/102718274791889610666/posts>
>>>
>>> This e-mail transmission may contain information that is proprietary,
>>> privileged and/or confidential and is intended exclusively for the
>>> person(s) to whom it is addressed. Any use, copying, retention or
>>> disclosure by any person other than the intended recipient or the
>> intended
>>> recipient's designees is strictly prohibited. If you are not the intended
>>> recipient or their designee, please notify the sender immediately by
>> return
>>> e-mail and delete all copies. OppenheimerFunds may, at its sole
>> discretion,
>>> monitor, review, retain and/or disclose the content of all email
>>> communications.
>>>
>>
>>
>> --
>>
>> We’re hiring if you know of any awesome Java Devops or Linux Operations
>> Engineers!
>>
>> Founder/CEO Spinn3r.com
>> Location: *San Francisco, CA*
>> blog: http://burtonator.wordpress.com
>> … or check out my Google+ profile
>> <https://plus.google.com/102718274791889610666/posts>
>>


Mime
View raw message