What's the best Garbage Collection Method for Hazlecast?

2,213 views
Skip to first unread message

Benjamin E.Ndugga

unread,
Nov 28, 2016, 4:36:34 AM11/28/16
to Hazelcast


 I have 62GB of RAM and most of the times I find myself using 90% of the heap size, I have set the the xms and xmx to 30GB yet most of my information is less then 1GB, Where does the rest of the Memory get used up?. I get to see this error and have to restart the instance

 
20 Nov 2016 13:45:25  WARN NonBlockingSocketWriter - [machine01]:5702 [dev] [3.6] hz._hzInstance_1_dev.IO.thread-out-2 Closing socket to endpoint Address[127.0.0.1]:49417, Cause:java.nio.channels.CancelledKeyException
java
.nio.channels.CancelledKeyException
    at sun
.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
    at sun
.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:77)
    at com
.hazelcast.nio.tcp.nonblocking.AbstractHandler.unregisterOp(AbstractHandler.java:73)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingSocketWriter.unschedule(NonBlockingSocketWriter.java:295)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingSocketWriter.handle(NonBlockingSocketWriter.java:344)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingSocketWriter.run(NonBlockingSocketWriter.java:423)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread.executeTask(NonBlockingIOThread.java:236)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread.processTaskQueue(NonBlockingIOThread.java:229)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread.runSelectLoop(NonBlockingIOThread.java:201)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread.run(NonBlockingIOThread.java:163)
20 Nov 2016 13:45:24  INFO TransactionManagerService - [machine01]:5702 [dev] [3.6] Committing/rolling-back alive transactions of client, UUID: b6f268ed-b1fb-4c57-9693-322106f7372e
20 Nov 2016 13:44:56  INFO TransactionManagerService - [machine01]:5702 [dev] [3.6] Committing/rolling-back alive transactions of client, UUID: 32233ce9-146d-48ff-8b22-32f93056e553
20 Nov 2016 13:44:53  INFO TransactionManagerService - [machine01]:5702 [dev] [3.6] Committing/rolling-back alive transactions of client, UUID: 061a1282-d4b6-48f2-922a-46ef55a8e4b3



Michael Pilone

unread,
Nov 28, 2016, 8:27:06 AM11/28/16
to haze...@googlegroups.com
I recommend using a tool like VisualVM (https://visualvm.github.io) to grab a heap dump and inspect it if you think there is a memory leak someplace. Most garbage collectors will only run (or only run aggressively) when they need space so if you're allocating 30GB but only using 1GB the GC may just let garbage grow a lot and clean it up with smaller collections. There are a lot of tools out there to monitor the GC and if you turn on GC logging you analyze the logs after the fact with tools like GCEasy (http://gceasy.io).

As for the best garbage collection method, it will vary based on your application but I've had good luck recently with the new Garbage 1st (G1) collector. I was having 5 and 10 second VM pauses for GC but I haven't seen that issue at all after switching to G1. Here's my GC options for what it is worth.

-XX:+UseG1GC
-XX:+UseStringDeduplication
-XX:MaxGCPauseMillis=300
-XX:G1HeapRegionSize=2m
-XX:+UseGCLogFileRotation
-XX:NumberOfGCLogFiles=5
-XX:GCLogFileSize=10M
-XX:+PrintGCDetails
-XX:+PrintGCDateStamps
-XX:+PrintStringDeduplicationStatistics
-Xloggc:../logs/garbageCollector.log
-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=../logs/

-mike

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.
To view this discussion on the web visit https://groups.google.com/d/msgid/hazelcast/55ac6cd1-b11e-4214-9fad-b62dde8768d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Nick Pratt

unread,
Nov 28, 2016, 8:32:44 AM11/28/16
to haze...@googlegroups.com
Just to clarify here - your JVM heap is set to 30Gb?  If so, how long are your major GC events?  That's a huge heap size for JVMs.  Most folks run heaps of 4Gb due to the costs of GC.  Ive seen heaps of 12-16Gb, but that required an awful lot of dedicated and frequent application analysis to fine tune the various generations within the heap space.

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+unsubscribe@googlegroups.com.

Benjamin E.Ndugga

unread,
Nov 28, 2016, 2:13:32 PM11/28/16
to Hazelcast

I think i shud do that before i make my decision on which Method to use. The Hazelcast take a while to run GC so I am forced to use the Management center to reduce the heap usage to below 60% percent. 30GB should be fine for the kind of information i need to cache into the IMAPs and bigges taking only 250MBs so if i have 5 Maps of that size It should be ookay

Benjamin E.Ndugga

unread,
Nov 28, 2016, 2:15:40 PM11/28/16
to Hazelcast
Hi Nick,

I am not too sure how often Hazelcast runs GC but from my findings it runs alot of Minor GCs and the Major GCs are barely run untill I intervene. I am thinking of using the Old GC Method and have it run asynchronous with out Application Pauses.


On Monday, 28 November 2016 16:32:44 UTC+3, Nick Pratt wrote:
Just to clarify here - your JVM heap is set to 30Gb?  If so, how long are your major GC events?  That's a huge heap size for JVMs.  Most folks run heaps of 4Gb due to the costs of GC.  Ive seen heaps of 12-16Gb, but that required an awful lot of dedicated and frequent application analysis to fine tune the various generations within the heap space.
On Mon, Nov 28, 2016 at 4:36 AM, Benjamin E.Ndugga <bjnd...@gmail.com> wrote:


 I have 62GB of RAM and most of the times I find myself using 90% of the heap size, I have set the the xms and xmx to 30GB yet most of my information is less then 1GB, Where does the rest of the Memory get used up?. I get to see this error and have to restart the instance

 
20 Nov 2016 13:45:25  WARN NonBlockingSocketWriter - [machine01]:5702 [dev] [3.6] hz._hzInstance_1_dev.IO.thread-out-2 Closing socket to endpoint Address[127.0.0.1]:49417, Cause:java.nio.channels.CancelledKeyException
java
.nio.channels.CancelledKeyException
    at sun
.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:73)
    at sun
.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:77)
    at com
.hazelcast.nio.tcp.nonblocking.AbstractHandler.unregisterOp(AbstractHandler.java:73)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingSocketWriter.unschedule(NonBlockingSocketWriter.java:295)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingSocketWriter.handle(NonBlockingSocketWriter.java:344)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingSocketWriter.run(NonBlockingSocketWriter.java:423)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread.executeTask(NonBlockingIOThread.java:236)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread.processTaskQueue(NonBlockingIOThread.java:229)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread.runSelectLoop(NonBlockingIOThread.java:201)
    at com
.hazelcast.nio.tcp.nonblocking.NonBlockingIOThread.run(NonBlockingIOThread.java:163)
20 Nov 2016 13:45:24  INFO TransactionManagerService - [machine01]:5702 [dev] [3.6] Committing/rolling-back alive transactions of client, UUID: b6f268ed-b1fb-4c57-9693-322106f7372e
20 Nov 2016 13:44:56  INFO TransactionManagerService - [machine01]:5702 [dev] [3.6] Committing/rolling-back alive transactions of client, UUID: 32233ce9-146d-48ff-8b22-32f93056e553
20 Nov 2016 13:44:53  INFO TransactionManagerService - [machine01]:5702 [dev] [3.6] Committing/rolling-back alive transactions of client, UUID: 061a1282-d4b6-48f2-922a-46ef55a8e4b3



--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.

Martijn Verburg

unread,
Nov 28, 2016, 2:59:09 PM11/28/16
to haze...@googlegroups.com
Hi Benjamin,

Try GC logging and throwing that output into a tool like GCViewer or (our) jClarity's Censum.  If you can get us a log I can take a look for you.

Cheers,
Martijn

To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+unsubscribe@googlegroups.com.

To post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.

Benjamin E.Ndugga

unread,
Nov 29, 2016, 9:08:59 AM11/29/16
to Hazelcast
Hi All,

So i have added the GC logging to my JVM Startup file I will monitor for about 2 days and see if there is anything more could share. So these are are my startup option, I am running on a 24 CPU node.

Please advise if the G1HeapRegionSize can be made bigger since I have set the xmx to 20GB

JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
JAVA_OPTS
="$JAVA_OPTS -XX:MaxGCPauseMillis=300"
JAVA_OPTS
="$JAVA_OPTS -XX:G1HeapRegionSize=32m"
JAVA_OPTS
="$JAVA_OPTS -XX:+UseGCLogFileRotation"
JAVA_OPTS
="$JAVA_OPTS -XX:ParallelGCThreads=18"
JAVA_OPTS
="$JAVA_OPTS -XX:NumberOfGCLogFiles=5"
JAVA_OPTS
="$JAVA_OPTS -XX:GCLogFileSize=10M"
JAVA_OPTS
="$JAVA_OPTS -XX:+PrintGCDetails"
JAVA_OPTS
="$JAVA_OPTS -XX:+PrintGCDateStamps"
JAVA_OPTS
="$JAVA_OPTS -Xloggc:/opt/hazlecast_logs/garbageCollector.log"
JAVA_OPTS
="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError"
JAVA_OPTS
="$JAVA_OPTS -XX:HeapDumpPath=/opt/hazlecast_logs/"

Cheers,
Martijn

Michael Pilone

unread,
Nov 29, 2016, 9:17:32 AM11/29/16
to haze...@googlegroups.com
GC tuning is a fine art; however from the documentation:

"The G1 GC is a regionalized and generational garbage collector, which means that the Java object heap (heap) is divided into a number of equally sized regions. Upon startup, the Java Virtual Machine (JVM) sets the region size. The region sizes can vary from 1 MB to 32 MB depending on the heap size. The goal is to have no more than 2048 regions."

So if you have 20GB that is roughly 20/2048 * 1024 = 10MB per region. You can leave the option off and the JVM will pick a reasonable default.

-mike



Cleber Muramoto

unread,
Nov 29, 2016, 5:19:32 PM11/29/16
to Hazelcast
I wouldn't bother grabbing a heap dump of 30+GB heap JVM instance.

Most profilers, including yjp, require large amounts of memory to open GB-sized heap dumps. 

I tried once with eclipse mat and I could only open the heap dump using a remote shell to the server :)

I think it might be better if he tried a horizontal-scale approach, err like a data-grid! 

If there's a memory leak of some sort it should present itself with smaller heap configuration.

@Benjamin: If you're running on RHEL 6+, you might be suffering from transparent huge pages. I had :(

Benjamin E.Ndugga

unread,
Dec 1, 2016, 4:00:55 AM12/1/16
to Hazelcast
Hi Cleber,

You could enlighten me on the huge pages as I am running on VMs, I am not soo good with the OS and yes, I am running RHEL 6.

Benjamin E.Ndugga

unread,
Dec 1, 2016, 4:10:49 AM12/1/16
to Hazelcast
Hi Mike,

To get this clear you are saying that G1 GC if I set the JVM option G1HeapRegionSize=32m this would mean that all the partitions will have a maximum of 32 MegaBytes? and each time they get filled there are Minor GCs?

Please do advise when the application can do Major GCs as well.

Thank You in Advance

Cleber Muramoto

unread,
Dec 1, 2016, 6:34:55 AM12/1/16
to Hazelcast

Michael Pilone

unread,
Dec 1, 2016, 8:28:15 AM12/1/16
to haze...@googlegroups.com
Benjamin,

The G1 collector uses a different layout for memory using many, fixed sized regions and marking those regions as eden, survivor, or humongous/old generation. I'm not an expert on G1 at all but my understanding is that there may be minor GCs at anytime that promote objects from one region to another. The benefit of G1 is that is can work on individual regions rather than one large block of eden or survivor space. It can also move only the surviving objects and then free an entire region quickly.

With a 32MB region and 20GB heap, you'll end up with 20 * 1024 / 32 = 640 regions. The documentation states that the JVM aims for 2048 regions so I'm assuming there is some reason the designer's chose that number but as with all things GC, you'll need to see how you're using it and tune appropriately.

I recommend reading https://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All for an introduction to G1. Then grab your GC logs and run them through an analyzer to look at GC timings and any warnings or hints the GC might be giving you for tuning. But of course look for obvious leaks or bad code first. The best GC in the world won't fix poor code that is leaking memory or allocating quicker than the memory can be reclaimed.

-mike

Benjamin E.Ndugga

unread,
Dec 4, 2016, 8:53:51 AM12/4/16
to Hazelcast

Hi Mike,

 Thank you so much the article is really informative, I guess with G1 GC its all about setting to –Xmx1G –Xms1G –XX:+UseG1GC –XX:+PrintGCDetails –XX:+PrintGCTimeStamps. This works well however I am still trying to optimise and see to it that the HeapUsage Stats go above 80% and now I have expanded the -Xmx to 60GB

 I have notice from the management centre that Memory Distribution the "Other  memory" grows faster than the "free memory". I am now trying to investigate that, If you have any ideas why that happens kindly share.

Thank you So much
Benji
 

Martijn Verburg

unread,
Dec 5, 2016, 6:14:20 AM12/5/16
to haze...@googlegroups.com
Hi Benjamin,

Are you able to send me your GC log?  Happy to take a look.

Cheers,
Martijn

On 4 December 2016 at 13:53, Benjamin E.Ndugga <bjnd...@gmail.com> wrote:

Hi Mike,

 Thank you so much the article is really informative, I guess with G1 GC its all about setting to –Xmx1G –Xms1G –XX:+UseG1GC –XX:+PrintGCDetails –XX:+PrintGCTimeStamps. This works well however I am still trying to optimise and see to it that the HeapUsage Stats go above 80% and now I have expanded the -Xmx to 60GB

 I have notice from the management centre that Memory Distribution the "Other  memory" grows faster than the "free memory". I am now trying to investigate that, If you have any ideas why that happens kindly share.

Thank you So much
Benji
 

 
 



On Thursday, 1 December 2016 16:28:15 UTC+3, Mike Pilone wrote:
Benjamin,

The G1 collector uses a different layout for memory using many, fixed sized regions and marking those regions as eden, survivor, or humongous/old generation. I'm not an expert on G1 at all but my understanding is that there may be minor GCs at anytime that promote objects from one region to another. The benefit of G1 is that is can work on individual regions rather than one large block of eden or survivor space. It can also move only the surviving objects and then free an entire region quickly.

With a 32MB region and 20GB heap, you'll end up with 20 * 1024 / 32 = 640 regions. The documentation states that the JVM aims for 2048 regions so I'm assuming there is some reason the designer's chose that number but as with all things GC, you'll need to see how you're using it and tune appropriately.

I recommend reading https://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All for an introduction to G1. Then grab your GC logs and run them through an analyzer to look at GC timings and any warnings or hints the GC might be giving you for tuning. But of course look for obvious leaks or bad code first. The best GC in the world won't fix poor code that is leaking memory or allocating quicker than the memory can be reclaimed.

-mike


On Dec 1, 2016, at 4:10 AM, Benjamin E.Ndugga <bjnd...@gmail.com> wrote:

Hi Mike,

To get this clear you are saying that G1 GC if I set the JVM option G1HeapRegionSize=32m this would mean that all the partitions will have a maximum of 32 MegaBytes? and each time they get filled there are Minor GCs?

Please do advise when the application can do Major GCs as well.

Thank You in Advance

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+unsubscribe@googlegroups.com.

To post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.

Michael Pilone

unread,
Dec 5, 2016, 11:34:14 AM12/5/16
to haze...@googlegroups.com
Benji,

I'd recommend starting with a smaller heap and reproducing the problem. Then you can use a heap analysis tool to look at what is consuming all the space in the heap. A 60GB heap is huge and it is going to be hard to analyze. Without knowing all the ins and outs of your software (and even if I did know them), guessing what is using heap is really hard. You really need to use some tools to analyze the heap dump and the GC logs to get an idea of what is going on. You may have a lot of data, a memory leak, or or who knows what else that is consuming memory.

-mike

On Dec 4, 2016, at 8:53 AM, Benjamin E.Ndugga <bjnd...@gmail.com> wrote:


Hi Mike,

 Thank you so much the article is really informative, I guess with G1 GC its all about setting to –Xmx1G –Xms1G –XX:+UseG1GC –XX:+PrintGCDetails –XX:+PrintGCTimeStamps. This works well however I am still trying to optimise and see to it that the HeapUsage Stats go above 80% and now I have expanded the -Xmx to 60GB 

 I have notice from the management centre that Memory Distribution the "Other  memory" grows faster than the "free memory". I am now trying to investigate that, If you have any ideas why that happens kindly share.

Thank you So much
Benji
 

 
 



On Thursday, 1 December 2016 16:28:15 UTC+3, Mike Pilone wrote:
Benjamin,

The G1 collector uses a different layout for memory using many, fixed sized regions and marking those regions as eden, survivor, or humongous/old generation. I'm not an expert on G1 at all but my understanding is that there may be minor GCs at anytime that promote objects from one region to another. The benefit of G1 is that is can work on individual regions rather than one large block of eden or survivor space. It can also move only the surviving objects and then free an entire region quickly.

With a 32MB region and 20GB heap, you'll end up with 20 * 1024 / 32 = 640 regions. The documentation states that the JVM aims for 2048 regions so I'm assuming there is some reason the designer's chose that number but as with all things GC, you'll need to see how you're using it and tune appropriately.

I recommend reading https://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All for an introduction to G1. Then grab your GC logs and run them through an analyzer to look at GC timings and any warnings or hints the GC might be giving you for tuning. But of course look for obvious leaks or bad code first. The best GC in the world won't fix poor code that is leaking memory or allocating quicker than the memory can be reclaimed.

-mike


On Dec 1, 2016, at 4:10 AM, Benjamin E.Ndugga <bjnd...@gmail.com> wrote:

Hi Mike,

To get this clear you are saying that G1 GC if I set the JVM option G1HeapRegionSize=32m this would mean that all the partitions will have a maximum of 32 MegaBytes? and each time they get filled there are Minor GCs?

Please do advise when the application can do Major GCs as well.

Thank You in Advance


-- 
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
To post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.

Benjamin E.Ndugga

unread,
Dec 9, 2016, 3:23:36 AM12/9/16
to Hazelcast
Hi Martijn,

Please see my GC log attached.




On Monday, 5 December 2016 14:14:20 UTC+3, Martijn Verburg wrote:
Hi Benjamin,

Are you able to send me your GC log?  Happy to take a look.

Cheers,
Martijn

On 4 December 2016 at 13:53, Benjamin E.Ndugga <bjnd...@gmail.com> wrote:

Hi Mike,

 Thank you so much the article is really informative, I guess with G1 GC its all about setting to –Xmx1G –Xms1G –XX:+UseG1GC –XX:+PrintGCDetails –XX:+PrintGCTimeStamps. This works well however I am still trying to optimise and see to it that the HeapUsage Stats go above 80% and now I have expanded the -Xmx to 60GB

 I have notice from the management centre that Memory Distribution the "Other  memory" grows faster than the "free memory". I am now trying to investigate that, If you have any ideas why that happens kindly share.

Thank you So much
Benji
 

 
 



On Thursday, 1 December 2016 16:28:15 UTC+3, Mike Pilone wrote:
Benjamin,

The G1 collector uses a different layout for memory using many, fixed sized regions and marking those regions as eden, survivor, or humongous/old generation. I'm not an expert on G1 at all but my understanding is that there may be minor GCs at anytime that promote objects from one region to another. The benefit of G1 is that is can work on individual regions rather than one large block of eden or survivor space. It can also move only the surviving objects and then free an entire region quickly.

With a 32MB region and 20GB heap, you'll end up with 20 * 1024 / 32 = 640 regions. The documentation states that the JVM aims for 2048 regions so I'm assuming there is some reason the designer's chose that number but as with all things GC, you'll need to see how you're using it and tune appropriately.

I recommend reading https://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All for an introduction to G1. Then grab your GC logs and run them through an analyzer to look at GC timings and any warnings or hints the GC might be giving you for tuning. But of course look for obvious leaks or bad code first. The best GC in the world won't fix poor code that is leaking memory or allocating quicker than the memory can be reclaimed.

-mike


On Dec 1, 2016, at 4:10 AM, Benjamin E.Ndugga <bjnd...@gmail.com> wrote:

Hi Mike,

To get this clear you are saying that G1 GC if I set the JVM option G1HeapRegionSize=32m this would mean that all the partitions will have a maximum of 32 MegaBytes? and each time they get filled there are Minor GCs?

Please do advise when the application can do Major GCs as well.

Thank You in Advance

--
You received this message because you are subscribed to the Google Groups "Hazelcast" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+...@googlegroups.com.
garbageCollector.log.0

Martijn Verburg

unread,
Dec 9, 2016, 11:01:05 AM12/9/16
to haze...@googlegroups.com
Hi Benjamin,

Can you re-create a log with the extra -XX:+PrintTenuringDistribution flag?  This will help us determine what your optimal memory pool sizing should be.

* The first suggestion - from looking at your JVM Resident Set Size (10.5 GB) your -Xmx should be set to roughly 24GB.  If I can see a log with 48 hours of data I can likely give you a more accurate number.

Drop me a mail at martijn AT jclarity DOT com if you'd like to go over this analysis in person.


Cheers,
Martijn

To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+unsubscribe@googlegroups.com.

To post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.

Benjamin E.Ndugga

unread,
Dec 14, 2016, 2:17:33 AM12/14/16
to Hazelcast
Hi Martin,
I have attached a new GC log from a JVM running with these switches:


JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"
JAVA_OPTS
="$JAVA_OPTS -XX:MaxGCPauseMillis=300"

JAVA_OPTS
="$JAVA_OPTS -XX:+UseGCLogFileRotation"
JAVA_OPTS
="$JAVA_OPTS -XX:ParallelGCThreads=20"

JAVA_OPTS
="$JAVA_OPTS -XX:NumberOfGCLogFiles=5"
JAVA_OPTS
="$JAVA_OPTS -XX:GCLogFileSize=10M"
JAVA_OPTS
="$JAVA_OPTS -XX:+PrintGCDetails"
JAVA_OPTS
="$JAVA_OPTS -XX:+PrintGCDateStamps"

JAVA_OPTS
="$JAVA_OPTS -Xloggc:/u02/hazelcast-logs/garbageCollector.log"
JAVA_OPTS
="$JAVA_OPTS -XX:+HeapDumpOnOutOfMemoryError"
JAVA_OPTS
="$JAVA_OPTS -XX:+PrintTenuringDistribution"
JAVA_OPTS
="$JAVA_OPTS -XX:HeapDumpPath=/u02/hazelcast-logs/"

I will be sending to a personal mail hereafter.

Regards,
Benjamin E.N

Cheers,
Martijn

garbageCollector.log.0

Martijn Verburg

unread,
Dec 14, 2016, 4:49:15 AM12/14/16
to haze...@googlegroups.com
Cool, thanks - I'll reply from my jclarity address.

*** Warning commercial bit follows ****

For anyone else, if you are having memory issues with Hazelcast or you'd just like to see what your optimal settings  should be then do grab the free trial of Censum - 

Cheers,
Martijn

To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+unsubscribe@googlegroups.com.

To post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.

Benjamin E.Ndugga

unread,
Jan 12, 2017, 6:53:45 AM1/12/17
to Hazelcast
Hi Team,

I think there was an issue with the older version hazlecast 3.6, I made a change to 3.7 keeping the same GC Algorithm as G1 and am surprised that the memory utilisation is low.

Cheers,
Martijn

Martijn Verburg

unread,
Jan 15, 2017, 9:14:07 AM1/15/17
to haze...@googlegroups.com
Hi Ben,

Yeah I discussed this with Peter, he fixed an issue to do with expensive unlocking as well.

Cheers,
Martijn

To unsubscribe from this group and stop receiving emails from it, send an email to hazelcast+unsubscribe@googlegroups.com.

To post to this group, send email to haze...@googlegroups.com.
Visit this group at https://groups.google.com/group/hazelcast.
Reply all
Reply to author
Forward
0 new messages