[
https://issues.apache.org/jira/browse/ARTEMIS-2193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16712922#comment-16712922
]
Francesco Nigro commented on ARTEMIS-2193:
------------------------------------------
[~kkaczkow] So you've gone OOM in ~4 hours? :(
It seems even worse...
I have added another commit: 6b2d9aee0f8b7c93b8e4c8027806c0ab63e11693
But it is useful just to reduce the heap footprint: I have noticed that the
heap dumps you've provided is filled of TransactionImpl and TaskHolder so my
bet was that there was many stores pending and never able to be flushed on the
disk.
I have met this same behaviour due to a race condition while dropping messages
and routing them.
I will try to dig a lil' more to see if the other protocols suffer from a
similar behaviour.
It would be very helpful if you can provide the code to trigger this behaviour
(the leak) and super helpful if you can try to do it using the core protocol to
see if it can work for you (supposing that you can change it), especially
because it has a real large message support (it streams messages in chunks).
Thanks for the collaboration (y)
> Artemis fails on OutOfMemoryError with fast producers
> -----------------------------------------------------
>
> Key: ARTEMIS-2193
> URL: https://issues.apache.org/jira/browse/ARTEMIS-2193
> Project: ActiveMQ Artemis
> Issue Type: Bug
> Components: Broker, OpenWire
> Affects Versions: 2.7.0, 2.6.3
> Reporter: Konrad Kaczkowski
> Priority: Critical
> Labels: performance
> Attachments: artemis.log, broker.xml, jvm-gc.log, resources_usage.png
>
>
> The broker fails on OOM Error in a couple of hours of testing with fast
> producers:
> * The Artemis broker with heap size of 2Gb, global-max-size of 400Mb, and
> global address-setting to apply DROP policy whenever memory exceeds 150Mb
> (max-size-bytes).
> - Two fast producers sending 100 KB messages to 2000 topics every 100 ms
> each
> - Client used: ActiveMQ 5.15.2 JMS
> - Tested on Artemis 2.6.3 and 2.7.0-SNAPSHOT
> - Testing time: 2 - 10 h until OOME occurs
> The heap size grows continuously until it runs of out memory. I tested
> DROP/PAGE/FAIL strategies with no difference. Attached are the log and the
> broker.xml configuration.
>
> Expectation: Having sharp memory limits the broker should handle with
> dropping messages on time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
