We would need some details: destination type (queue or topic),
persistent or non persistent message, memory/temp usage, etc.
On 19/12/2019 07:40, kyadari wrote:
> We have application that use ActiveMQ to transfer data from
> source database to destination Database
> Application is getting issue for every 50+ days i.e. OutOfMemoryError in
> activeMQ and application gets stopped. After restarting the AMQ services, it
> will resume the transfer.
> INFO | jvm 1 | 2019/09/06 00:56:34 | java.lang.OutOfMemoryError: Java
> heap space
> INFO | jvm 1 | 2019/09/06 00:56:58 | Heap dump file created [4259842078
> bytes in 23.626 secs]
> Currently activemq heap memory set to 4 GB. We continuously monitor AMQ
> using JConsole and found memory is consuming more than i.e. 2.8 GB
> This system is only dedicated for AMQ and application
> ActiveMQ version-5.14.1
> JDK version : 1.8 Update 60
> Could you please help to provide the root cause and fix on the issue.
> Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html >
for memory usage, could be useful taking some screenshot of objects in the
heap dump with VisualVM :
- screenshot/s of objects in the heap dump sorted by count;
- screenshot/s of objects in the heap dump sorted by size;
You should also describe a few things about the usage pattern. Is there an
increasing number of unconsumed messages over time? Do you use a
non-trivial number of scheduled messages?
And for the heap usage itself, do you see a low staeady state but a sudden
spike at the time that the OOM occurs, or is there a slow growth that
eventually hits the max heap size? You said you're continually monitoring
the free heap (after a full GC, presumably, since heap usage at any other
time is largely irrelevant) and it's at 1.2 GB free (2.8 used), which
sounds fine, but is that how it was just before the crash? Also, which GC
strategy are you using? And 8u60 is pretty old and there were a number of
improvements to the G1GC strategy early in the Java 8 development cycle, so
if you're using G1, is a JVM upgrade an option to rule out a G1 bug?
The error message indicates that it created a heap dump. Have you analyzed