mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
64 lines
4.3 KiB
Plaintext
64 lines
4.3 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * nodes/nodes-cluster-resource-configure.adoc
|
|
|
|
:_mod-docs-content-type: CONCEPT
|
|
[id="nodes-cluster-resource-configure-about_{context}"]
|
|
= Understanding how to manage application memory
|
|
|
|
[role="_abstract"]
|
|
You can review the following concepts to learn how {product-title} manages compute resources so that you can lean how to keep your cluster running efficiently.
|
|
|
|
For each kind of resource (memory, CPU, storage), {product-title} allows optional *request* and *limit* values to be placed on each container in a pod.
|
|
|
|
Note the following information about memory requests and memory limits:
|
|
|
|
* *Memory request*
|
|
|
|
- The memory request value, if specified, influences the {product-title} scheduler. The scheduler considers the memory request when scheduling a container to a node, then fences off the requested memory on the chosen node for the use of the container.
|
|
|
|
- If a node's memory is exhausted, {product-title} prioritizes evicting its containers whose memory usage most exceeds their memory request. In serious cases of memory exhaustion, the node OOM killer might select and kill a process in a container based on a similar metric.
|
|
|
|
- The cluster administrator can assign quota or assign default values for the memory request value.
|
|
|
|
- The cluster administrator can override the memory request values that a developer specifies, to manage cluster overcommit.
|
|
|
|
* *Memory limit*
|
|
|
|
- The memory limit value, if specified, provides a hard limit on the memory that can be allocated across all the processes in a container.
|
|
|
|
- If the memory allocated by all of the processes in a container exceeds the memory limit, the node Out of Memory (OOM) killer immediately selects and kills a process in the container.
|
|
|
|
- If both memory request and limit are specified, the memory limit value must be greater than or equal to the memory request.
|
|
|
|
- The cluster administrator can assign quota or assign default values for the memory limit value.
|
|
|
|
- The minimum memory limit is 12 MB. If a container fails to start due to a `Cannot allocate memory` pod event, the memory limit is too low. Either increase or remove the memory limit. Removing the limit allows pods to consume unbounded node resources.
|
|
|
|
The steps for sizing application memory on {product-title} are as follows:
|
|
|
|
. *Determine expected container memory usage*
|
|
+
|
|
Determine expected mean and peak container memory usage. For example, you could perform separate load testing. Remember to consider all the processes that could potentially run in parallel in the container, such as any ancillary scripts that might be spawned by the main application.
|
|
|
|
. *Determine risk appetite*
|
|
+
|
|
Determine risk appetite for eviction. If the risk appetite is low, the container should request memory according to the expected peak usage plus a percentage safety margin. If the risk appetite is higher, it might be more appropriate to request memory according to the expected mean usage.
|
|
|
|
. *Set container memory request*
|
|
+
|
|
Set the container memory request based on the above. The request should represent the application memory usage as accurately as possible. If the request is too high, cluster and quota usage will be inefficient. If the request is too low, the chances of application eviction increase.
|
|
|
|
. *Set container memory limit, if required*
|
|
+
|
|
Set the container memory limit, if required. Setting a limit has the effect of immediately killing a container process if the combined memory usage of all processes in the container exceeds the limit. Setting a limit might make unanticipated excess memory usage obvious early (_fail fast_). However, setting a limit also terminates processes abruptly.
|
|
+
|
|
Note that some {product-title} clusters might require a limit value to be set; some might override the request based on the limit; and some application images rely on a limit value being set as this is easier to detect than a request value.
|
|
+
|
|
If the memory limit is set, it should not be set to less than the expected peak container memory usage plus a percentage safety margin.
|
|
|
|
. *Ensure applications are tuned*
|
|
+
|
|
Ensure your applications are tuned with respect to configured request and limit values, if appropriate. This step is particularly relevant to applications which pool
|
|
memory, such as the JVM. The rest of this page discusses this.
|