activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reynald Borer <reynald.bo...@gmail.com>
Subject Re: Slow throughput after several hundred messages
Date Mon, 13 Dec 2010 18:28:10 GMT

 Hi guys,


Have you tried to enable GC logs to see if maybe a full GC is happening while everything is
slowed down?


In the past I encountered the same issue where for an unknown reason the GC activity was suddenly
high, making a full GC of 0.2 seconds every second. I spotted this issue because the GC logs
where active (and of course also because everything seemed to be slowed down).


This happened with the amq persistence adapter and not kahaDB (using version 5.3.0). And now
the problem is solved simply because the number of connection has been lowered, which is not
an ideal solution. So I'm really interested if you find something useful.


Regards,
Reynald


On Monday, December 13, 2010 at 15:58 , Robert.Sloss@Misys.com wrote:

> 
> I have tried each of the different cursor types with 5.4.1, but since
> downloading the 5.4.2 version, I have not changed the cursor used, so this
> is the default configuration, where no cursor is defined for queues - this
> should result in the default store cursor being used. 
> 
> I have just tried with enableJournalDiskSyncs = "false", but this results in
> similar slow processing after a batch of messages have been processed.
> Although with this approach the consumer thread seemed to be more hindered
> than the producer, as messages were being produced onto the test queue
> around 3-4 times faster than they were being consumed. Once again I get the
> same EOFException thrown and message production/consumption seems to slow
> periodically, for greater periods the more messages I process.
> -- 
> View this message in context: http://activemq.2283324.n4.nabble.com/Slow-throughput-after-several-hundred-messages-tp3082431p3085521.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
> 
> 
> 
> 



Mime
  • Unnamed multipart/alternative (inline, 8-Bit, 0 bytes)
View raw message