> ...each "address size" byte takes 40- 160 "container" bytes.
Can you elaborate on how this was calculated? Also, what exactly do you mean by "'container' bytes"? Are you talking about JVM heap? Keep in mind that as far as the broker is concerned memory usage won't change when running in a container or on bare metal. It's also worth noting that the messages represented by the address size are far from the only thing in memory. Every object dedicated to running the broker is also in memory as well. Have you tried acquiring any heap dumps? If so, did you analyze them? If so, what was the result of that analysis? Justin On Fri, Sep 8, 2023 at 2:06 AM Tobias Månsson (external) <tobias.mans...@husqvarnagroup.com.invalid> wrote: > We have a Artemis 2.30.0 2 node cluster setup running in amazoncorretto:17 > container image (Java 17 JRE), with persistance disabled. > > > We've had issues with high memory usage for our Artemis broker for a long > time, but recently several events raised a possible candidate to the cause. > There were sudden drops in address size correlating to container memory > drops, and calculations show that each "address size" byte takes 40- 160 > "container" bytes. > > > Is this normal and intended? > > > Should the parameter max-size-bytes be multiplied by say 100 to get > "actually" container memory usage? > > > The information in this email may be confidential and/or legally > privileged. It has been sent for the sole use of the intended recipient(s). > If you are not an intended recipient, you are strictly prohibited from > reading, disclosing, distributing, copying or using this email or any of > its contents, in any way whatsoever. If you have received this email in > error, please contact the sender by reply email and destroy all copies of > the original message. Please also be advised that emails are not a secure > form for communication, and may contain errors. >
