activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clebert Suconic <>
Subject Re: Artemis use of PhantomReference impacting GC performance
Date Thu, 04 Feb 2016 23:34:05 GMT
I talked to someone, and we all raised the same question: When are you
measuring this?

By your earlier comment I had the impression you are measuring

"However *once I start up* an external JMS client subscribed to the
Topic the PhantomReferences appear and the GCs slow down as shown in
the next image.  The messaging is non-XA with auto-ack."

This could be Netty bootstrapping the PooledByteBuffer arena. We would
need to see this during a steady measurement. Can you provide some
more information?

On Thu, Feb 4, 2016 at 4:14 PM, Clebert Suconic
<> wrote:
> Are you measuring this during a sustained load period? Measuring
> things like this during a ramp up will be likely cause false positives
> (as netty for instance would still be bootstrapping the reusable pool
> area).
> I know someone with a lot of experience on turning parallel GC, and
> I'm gathering some information for this thread. (I will ask him to
> post here).
> Also: you were with JBoss 4. You probably also have different JDKs
> now. so perhaps different settings would be required for your load?
> On Thu, Feb 4, 2016 at 2:44 PM, Justin Bertram <> wrote:
>> Thanks for explaining your use-case a bit more.  That helps.  In my opinion the key
statement here is that Artemis isn't working in a vacuum - it actually plays quite a small
role in a much larger application.  Your overall use-case involves low message volume and
low latency requirements.
>> Can you elaborate any more on what specifically the JMS related code is doing?  For
example, are you using transactions?  What connection factory are you using?  Are your clients
local or remote or both?  How many clients do you have and what kind are they (e.g. producer
or consumer)?  The more information you can provide the more likely it is we will be able
to help.
>> Personally I think comparing Artemis to JBoss Messaging is not terribly useful. 
We're talking about implementation level details here as they are related to GC.  We're not
going to move back to JBoss Messaging's architecture and we're not going to drop Netty so
let's focus on things we might actually be able to change.  It may be that your client code
can be optimized or written differently to take advantage of how Artemis is implemented or
it may be that you need to tune the GC differently.  We can't help much without more data
about your use-case, application, environment, etc.  Performance related issues like this
are typically the most difficult to work through, especially on a mailing list.  If you could
provide an actual test demonstrating a problem that would be ideal.
>> Justin
>> ----- Original Message -----
>> From: "jim_b_o" <>
>> To:
>> Sent: Thursday, February 4, 2016 12:17:35 PM
>> Subject: Re: Artemis use of PhantomReference impacting GC performance
>> I think the memory comparison is fair in this case.  The main application
>> load is events received via a ResourceAdapter passed to POJOs which process
>> and return responses via the same ResourceAdapter.  There is no Web
>> component and EJBs are only for admin functions and not being invoked during
>> these tests.  The JMS is an outbound feed of a small subset of the processed
>> events.  So the only container code under test is the JMS and a small part
>> of the ResourceAdapter glue although most of that is done using Spring and
>> is the same in both containers.  The POJOs and ResourceAdapter are identical
>> in both systems.
>> This does impact application performance.  I don't doubt that Artemis can
>> handle more messages and do so faster than the old messaging but it is not
>> operating in a vacuum.  The JMS performance is not a critical aspect of this
>> system.  The critical aspect is how quickly and reliably the POJOs can
>> receive/process/respond via the ResourceAdapter.  These longer
>> stop-the-world GCs that appear to be due to the JMS cause hick-ups in that
>> processing.  The JMS is doubling the GC pause time.
>> I'll run another test to confirm if the excess PhantomReferences are from
>> Netty or XNIO.  I'm currently connecting the JMS and EJB client
>> simultaneously so I'll separate them.
>> --
>> View this message in context:
>> Sent from the ActiveMQ - Dev mailing list archive at
> --
> Clebert Suconic

Clebert Suconic

View raw message