You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: content/en/docs/deployment/private-cloud/private-cloud-deploy/jvm-memory-tuning.md
+39-61Lines changed: 39 additions & 61 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -7,75 +7,61 @@ weight: 10
7
7
---
8
8
## Introduction
9
9
10
-
Mendix Runtime and any Mendix apps run in a Java Virtual Machine.
11
-
12
-
Most Java Virtual Machines (including the one used in Mendix on Kubernetes) are based on the HotSpot Java VM.
13
-
The HotSpot VM uses a garbage collector to free up unused memory.o
14
-
15
-
Running the garbage collector causes a negative performance impact; the Hotspot VM tries to only run garbage collection when absolutely necessary (for example, when memory usage reaches a certain threshold).
10
+
Mendix Runtime and any Mendix apps run in a Java Virtual Machine. Most Java Virtual Machines (including the one used in Mendix on Kubernetes) are based on the HotSpot Java VM. The HotSpot VM uses a garbage collector to free up unused memory. However, running the garbage collector causes a negative performance impact. The Hotspot VM tries to only run garbage collection when absolutely necessary (for example, when memory usage reaches a certain threshold).
16
11
17
12
{{% alert color="info" %}}
18
13
For a comprehensive guide explaining how the HotSpot VM performs garbage collection, see the [official Java documentation](https://docs.oracle.com/en/java/javase/21/gctuning/index.html).
19
14
{{% /alert %}}
20
15
21
-
## Memory tuning
16
+
## Memory Tuning
22
17
23
-
In most cases, Mendix on Kubernetes doesn't need advanced memory tuning.
24
-
Starting with Operator version 2.26, the default memory settings have been aligned with Mendix Cloud and are based on typical Mendix app usage patterns.
18
+
In most cases, Mendix on Kubernetes does not need advanced memory tuning. Starting with Operator version 2.26, the default memory settings have been aligned with Mendix Cloud and are based on typical Mendix app usage patterns.
25
19
26
20
{{% alert color="warning" %}}
27
-
Manual adjusting JVM memory usage is only needed in some cases - when the default memory settings leave unused memory.
21
+
Manual adjusting JVM memory usage is only needed in some cases, when the default memory settings leave unused memory.
28
22
{{% /alert %}}
29
23
30
-
### Types of memory
24
+
### Types of Memory
31
25
32
26
In the HotSpot VM, memory is split into two regions, **Heap** and **Non-Heap**.
33
27
34
-
***Heap** memory is used to store temporary _data_, including microflow variables, entities and internal state of the Mendix Runtime and third-party libraries.
35
-
***Non-Heap** memory stores _code_, internal Java VM data and data from non-Java components, such as the [BAPI Connector](/appstore/modules/sap/sap-bapi-connector/#setup-environment) or machine learning modules from [ML Kit](/refguide/machine-learning-kit/).
28
+
***Heap** memory is used to store temporary data, including microflow variables, entities, and internal states of the Mendix Runtime and third-party libraries.
29
+
***Non-Heap** memory stores code, internal Java VM data and data from non-Java components, such as the [BAPI Connector](/appstore/modules/sap/sap-bapi-connector/#setup-environment) or machine learning modules from [ML Kit](/refguide/machine-learning-kit/).
36
30
37
-
There's a fixed boundary between **Heap** and **Non-Heap** memory: any memory reserved for the **Heap** cannot be used for any other purpose; all remaining memory will be assigned to the **Non-Heap** region.
31
+
There is a fixed boundary between **Heap** and **Non-Heap** memory. Any memory reserved for the heap cannot be used for any other purpose. All remaining memory is assigned to the **Non-Heap** region.
It's not possible to dynamically adjust the amount of **Heap** and **Non-Heap** regions of a running app, this needs to be specified before starting an app.
35
+
It is not possible to dynamically adjust the amount of **Heap** and **Non-Heap** regions of a running app. This needs to be specified before starting an app.
Starting with Operator version 2.26, the default memory settings use the following rules:
46
40
47
41
| Container memory limit | JVM non-heap size |
48
-
|------------------------|-------------------|
49
-
| Less than 2 GB | Half of the limit (but at least 300 MB) |
50
-
| Between 2 and 4 GB | 1 GB|
51
-
| Between 4 and 8 GB | 1.5 GB|
52
-
| Between 8 and 16 GB | 2 GB|
53
-
| Between 16 and 32 GB | 3 GB|
54
-
| 32 GB or more | 4 GB|
42
+
|---|---|
43
+
| Less than 2 GB | Half of the limit (but at least 300 MB) |
44
+
| Between 2 and 4 GB | 1 GB |
45
+
| Between 4 and 8 GB | 1.5 GB |
46
+
| Between 8 and 16 GB | 2 GB |
47
+
| Between 16 and 32 GB | 3 GB |
48
+
| 32 GB or more | 4 GB |
55
49
56
50
All other memory is allocated to the heap.
57
51
58
52
{{% alert color="info" %}}
59
-
Older Operator versions don't set any memory configuration.
60
-
In this case, the HotSpot VM allocates 25% of the memory limit to heap memory, and the rest is assigned to non-heap memory.
61
-
This assignment is not optimal, as typical Mendix apps primarily benefit from heap memory.
53
+
Older Operator versions do not set any memory configuration. In this case, the HotSpot VM allocates 25% of the memory limit to heap memory, and the rest is assigned to non-heap memory. This assignment is not optimal, as typical Mendix apps primarily benefit from heap memory.
62
54
{{% /alert %}}
63
55
64
-
### Metrics-based tuning
56
+
### Metrics-Based Tuning
65
57
66
58
{{% alert color="info" %}}
67
-
Instead of freeing memory, the HotSpot VM prefers to recycle/reuse it.
68
-
When looking at total memory usage in a container (for example using `kubectl top pods` or data collected by `kube-state-metrics`),
69
-
the total memory usage will not reflect internal details.
70
-
71
-
For example, the JVM **Heap** might be underutilized, but will show as "used memory" in the container memory usage.
72
-
73
-
To have a clear picture of how memory is allocated and used, use Prometheus metrics.
59
+
Instead of freeing memory, the HotSpot VM prefers to recycle/reuse it. When looking at total memory usage in a container (for example using `kubectl top pods` or data collected by `kube-state-metrics`), the total memory usage will not reflect internal details. For example, the JVM **Heap** might be underutilized, but will show as *used memory* in the container memory usage. To have a clear picture of how memory is allocated and used, use Prometheus metrics.
74
60
{{% /alert %}}
75
61
76
-
For examples how to read JVM memory usage graphs, see the [Java Memory Usage](/refguide/java-memory-usage/) document.
62
+
For examples how to read JVM memory usage graphs, see [Java Memory Usage](/refguide/java-memory-usage/).
77
63
78
-
### Adjusting memory in Mendix on Kubernetes
64
+
### Adjusting Memory in Mendix on Kubernetes
79
65
80
66
In a [Standalone environment](/developerportal/deploy/private-cloud-operator/#edit-cr), the JVM heap size can be adjusted in the `jvmMemorySettings` section of the `MendixApp` CR.
81
67
@@ -99,56 +85,48 @@ spec:
99
85
100
86
Removing the `jvmMemorySettings` section will switch to the [default memory allocation](#default-memory-allocation) settings.
101
87
102
-
Starting with Operator version 2.26, the JVM heap size should be adjusted as documented in this section.
103
-
If you have an environment using any of the following custom JVM options, they _will not be applied_ to the app configuration (will be removed):
88
+
Starting with Operator version 2.26, the JVM heap size should be adjusted as documented in this section. If you have an environment using any of the following custom JVM options, they will not be applied to the app configuration and will instead be removed:
104
89
105
90
* `-Xms` - minimal heap size
106
91
* `-Xmx` - heap size limit
107
92
* `-XX:MinRAMPercentage` - heap size limit, in percentages for environments with less than 250MB of container memory
108
93
* `-XX:MaxRAMPercentage` - heap size limit, in percentages for environments with more than 250MB of container memory
109
94
* `-XX:InitialRAMPercentage` - minimal heap size, in percentages
110
95
111
-
## Addressing memory issues
96
+
## Addressing Memory Issues
112
97
113
-
On a typical desktop system and many server environments, reaching or exceeding the memory limit is not a problem.
98
+
On a typical desktop system and many server environments, reaching or exceeding the memory limit is not a problem. The operating system will move some of the memory contents to a storage device such as an SSD or hard drive. However, this will likely cause a major performance penalty, and in Kubernetes is [disabled by default](https://kubernetes.io/docs/concepts/cluster-administration/swap-memory-management/).
114
99
115
-
The operating system will move some of the memory contents to a storage device such as an SSD or hard drive.
116
-
However, this will likely cause a major performance penalty, and in Kubernetes is [disabled by default](https://kubernetes.io/docs/concepts/cluster-administration/swap-memory-management/).
100
+
When an app tries to use more memory than its container memory limit, it will be terminated by Kubernetes (OOMKilled) and will effectively crash. To prevent performance degradation and the app from crashing, it might need its memory to be adjusted.
117
101
118
-
When an app tries to use more memory than it's container memory limit, it will be terminated by Kubernetes (OOMKilled) and will effectively crash.
102
+
### Addressing Out Of Memory Crashes
119
103
120
-
To prevent performance degradation and the app from crashing, it might need its memory to be adjusted.
121
-
122
-
### Addressing OOMKilled crashes
123
-
124
-
An OOMKilled (Out Of Memory-killed) event happens when an app attempts to use more memory than specified in its container limit:
104
+
An *OOMKilled* (Out Of Memory-killed) event happens when an app attempts to use more memory than specified in its container limit:
To address this issue, choose one of the following options:
133
113
134
-
* Recommended fix: increase the core resource memory (_requests_ and _limits_).
135
-
* Alternatively, if the Prometheus metrics show that the heap memory usage is low: decrease the heap memory size.
114
+
* Recommended fix: increase the core resource memory (**requests** and **limits**).
115
+
* Alternatively, if the Prometheus metrics show that the heap memory usage is low, decrease the heap memory size.
136
116
137
117
{{% alert color="info" %}}
138
-
This can also happen if a node is overcommitted (not enough available memory for app pods).
139
-
140
-
To prevent overcommitment, adjust the memory _requests_ to match the container _limits_.
118
+
This can also happen if a node is overcommitted (not enough available memory for app pods). To prevent overcommitment, adjust the memory **requests** to match the container **limits**.
A `java.lang.OutOfMemoryError` exception happens when the JVM **Heap** is full and doesn't have enough available memory to perform an action (such as a Microflow or a Java Custom Action).
123
+
A `java.lang.OutOfMemoryError` exception happens when the JVM heap is full and does not have enough available memory to perform an action (such as a Microflow or a Java Custom Action).
0 commit comments