Memory configuration mismatch -> OOM

When scaling down consumers in my test I would expect the shareded queue brokers to buffer messages until consumer can catch up. That works as first, but quite soon brokers start to die due to an OOM situation.

Looking into the broker template I do see the following two parameters:

- description: Memory limits for container
  name: BROKER_MEMORY_LIMIT
  value: 512Mi
- description: Global max size for all addresses in broker. Cannot be larger than
  a quarter of BROKER_MEMORY_LIMIT
  name: GLOBAL_MAX_SIZE
  value: 128Mb

Assuming the latter parameter targets the Java VM heap space this would be a problem because the startup script of the brokers already splits the BROKER_MEMORY_LIMIT in half in order to compensate for JVM overhead:

See the startup log:

-Xms256m -Xmx256m -XX:+UseParallelGC …

So I think the default settings for BROKER_MEMORY_LIMIT should be 1024Miinstead.

[lulf]

@ctron Ah sorry yes, you are right, 128MB for the rest of course. Clearly it would be useful if we could just leave global_max up to the broker 😃 (which I think it does if you set to -1). In any case, maybe we should update the defaults anyway, as I don’t think this little memory for Artemis is well tested.

[lulf]

I believe this is fixed in 0.26.3 and newer