-
Bug
-
Resolution: Done
-
Major
-
AMQ 7.8.3.GA
-
None
-
False
-
False
-
-
Using init-container, the AMQ pod has Xmx value equals to 1/2 resources.requests.memory, as defined in the Activemqartemis CR at deploy time. There is no way to change this value by updating the CR after initial deploy (see ENTMQBR-5748).
In this example, I'm initially setting requests==limits with 1 CPU and 1GiB of memory. After the initial deployment, I directly edit the broker STS in order to raise resources to 3 CPU and 3GiB of memory (workaround).
Non-terminated Pods: (17 in total) Namespace Name CPU Requests CPU Limits Memory Requests Memory Limits Age --------- ---- ------------ ---------- --------------- ------------- --- broker my-broker-ss-0 3 (19%) 3 (19%) 3Gi (4%) 3Gi (4%) 9m37s broker my-broker-ss-1 3 (19%) 3 (19%) 3Gi (4%) 3Gi (4%) 10m
As you can see, the workaround works, but when I check broker logs I still have the global-max-size value computed from the deployment value (256 MiB, where Xmx == 1/2 deployment mem == 512 MiB):
2021-11-25 12:26:01,561 INFO [org.apache.activemq.artemis.core.server] AMQ221057: Global Max Size is being adjusted to 1/2 of the JVM max size (-Xmx). being defined as 268,435,456
This makes impossible to recover from a situation where you have a huge backlog of messages and the broker needs to load the whole journal into memory at startup.
A workaround here would be to use init-container to overwrite the global-max-size value, but this is not something OLM/GUI users are used to do.
- incorporates
-
ENTMQBR-5210 Allow operator to set global-max-size
- Closed
-
ENTMQBR-6536 The OpenWire protocol triggers an OutOfMemoryError on large messages (200K body, bellow 500K journal-buffer-size)
- Closed
- is cloned by
-
ENTMQBR-6549 [doc] Cannot raise global-max-size
- Closed
- mentioned in
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...
-
Page Loading...