activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From nigro_franz <nigro....@gmail.com>
Subject Re: ActiveMQ broker becomes unresponsive after sometime
Date Tue, 23 May 2017 08:54:55 GMT
Hi Tim!

Answers inlined


Tim Bain wrote
> Shenandoah is aimed at large JVMs (the page that link points to says 20GB 
> or bigger), so I wouldn't just go trying it without understanding what its 
> strengths and weaknesses are. 

Partially disagree, that link was only a fast overview of what Shenandoah
is: as you rightly said, there are strengths and weaknesses beyond what a
single page link could explain about a GC algorithm.
A better comparison of G1 vs Shenandoah is here:
https://www.infoq.com/presentations/G1-Shenandoah

TLDR: 
1) "mostly" G1 (region based, SATBs, uses write barriers etc etc) BUT with
no remembered sets 
2) no generational anymore: young won't die first!!
3) concurrent relocation using Brooks pointers
(https://rkennke.wordpress.com/2013/10/23/shenandoah-gc-brooks-pointers/) 
-> more memory overhead and lower throughput (eg read barriers, multiple
copies)
4) won't pause while evacuate

IMHO the most important point that could make it a good match to be used to
run a Java broker is 2: if you've an application in which you already know
that queues/messages won't die soon (from a tenuring age pov), regardless to
he planned heap size (=== could be not a huge heap) it makes sense to give
it a try, taking in account the memory overhead involved.

The common idea that S, is will suited to manage huge heaps is just an added
benefit related to not being anymore bounded by object copy/marking
performances in minor GCs like G1. 

The reasons why I've given the advice of giving it a try is mostly dependent
by the fact that I'm assuming a very "busy" (from the copy operations pov)
young generation or a very big old generation: like the Parallel GC, S.
performs Full GCs using multiple threads (G1 not AFAIK), hence in the worst
that a Full GC has to happen I'm expecting it will be shorter than G1. 


Tim Bain wrote
> Are you associated with the company? 

Not, I'm not, I've used it just to have a simple GC viewer to be used
instead of the ones provided by other products.


Tim Bain wrote
> Can you share more about your experience with G1? In particular, was the 
> slow behavior during incremental Old Gen collections, or during an actual 
> full GC? Theoretically, G1 is supposed to avoid full GCs by doing 
> incremental Old Gen GCs; are you saying that you weren't able to get it to 
> do that? 

 
Yes I'll do for sure :) 
it is just a matter to write something on this forum, but need time to make
the results more than a simple collection of GC logs :)
As preview: with Artemis if you have a fast rate of message arrival (with no
consumers), no expiration queues and you set the broker to retain them
occupying the most of your old generation without leaving enough space to
let the young generations (ie the fresh arrived messages) age in peace (ie
having enough contiguous free space), G1 will likely run a lot of Full GCs.
In this very uncommon case (it is full of anti-pattern) a Parallel GC (or
S.) is very likely to perform at least shorter Full GCs, mostly due to the
uses of multiple threads while doing it.
Makes sense?

Regards,
Francesco  



--
View this message in context: http://activemq.2283324.n4.nabble.com/ActiveMQ-broker-becomes-unresponsive-after-sometime-tp4725278p4726439.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.

Mime
View raw message