[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: G1GC CPU Spike


Explicitly setting Xmn with G1 basically results in overriding the target pause-time goal, thus should be avoided.

http://www.oracle.com/technetwork/articles/java/g1gc-1984535.html

 

Thomas

 

 

From: rajpal reddy [mailto:rajpalreddy444@xxxxxxxxx]
Sent: Mittwoch, 13. Juni 2018 17:27
To: user@xxxxxxxxxxxxxxxxxxxx
Subject: Re: G1GC CPU Spike

 

we have this has the Heap settings . is the HEAP_NEWSIZE is required only for CMS. can we get rid of that for G1GC so that it can be used?

MAX_HEAP_SIZE="8192M"

HEAP_NEWSIZE=“800M"

 

On Jun 13, 2018, at 11:15 AM, Chris Lohfink <clohfink@xxxxxxxxx> wrote:

 

That metric is the total number of seconds spent in GC, it will increase over time with every young gc which is expected. Whats interesting is the rate of growth not the fact that its increasing. If graphing tool has option to graph derivative you should use that instead.

 

Chris



On Jun 13, 2018, at 9:51 AM, rajpal reddy <rajpalreddy444@xxxxxxxxx> wrote:

 

jvm_gc_collection_seconds_count{gc="G1 Young Generation”} and also young generation seconds count keep increasing

 

<PastedGraphic-1.png>

 

On Jun 13, 2018, at 9:52 AM, Chris Lohfink <clohfink@xxxxxxxxx> wrote:

 

The gc log file is best to share when asking for help with tuning. The top of file has all the computed args it ran with and it gives details on what part of the GC is taking time. I would guess the CPU spike is from full GCs which with that small heap of a heap is probably from evacuation failures. Reserving more of the heap to be free (-XX:G1ReservePercent=25) can help, along with increasing the amount of heap. 8GB is pretty small for G1, might be better off with CMS.

Chris


On Jun 13, 2018, at 8:42 AM, rajpal reddy <rajpalreddy444@xxxxxxxxx> wrote:

Hello,

we are using G1GC and noticing garbage collection taking a while and during that process we are seeing cpu spiking up to 70-80%. can you please let us know. if we have to tune any parameters for that. attaching the cassandra-env file with jam-options.<cassandra-env.txt>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxxx



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: user-help@xxxxxxxxxxxxxxxxxxxx

 

 

 

The contents of this e-mail are intended for the named addressee only. It contains information that may be confidential. Unless you are the named addressee or an authorized designee, you may not copy or use it, or disclose it to anyone else. If you received it in error please notify us immediately and then destroy it. Dynatrace Austria GmbH (registration number FN 91482h) is a company registered in Linz whose registered office is at 4040 Linz, Austria, Freistädterstraße 313