Project: Flink (App Definition and Development / Streaming & Messaging)
File: mem_tuning.md

title: "Memory Tuning Guide" weight: 5 type: docs aliases: /deployment/memory/mem_tuning.html /ops/memory/mem_tuning.html <!-- Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. --> In addition to the , this section explains how to set up memory depending on the use case and which options are important for each case. It is recommended to configure ( or ) or its components for where you want to declare how much memory is given to Flink itself. Additionally, you can adjust JVM metaspace if it causes . The total Process memory is not relevant because JVM overhead is not controlled by Flink or the deployment environment, only physical resources of the executing machine matter in this case. It is recommended to configure ( or ) for the containerized deployments ( or ). It declares how much memory in total should be assigned to the Flink JVM process and corresponds to the size of the requested container. <span class="label label-info">Note</span> If you configure the total Flink memory Flink will implicitly add JVM memory components to derive the total process memory and request a container with the memory of that derived size. {{< hint warning >}} Warning: If Flink or user code allocates unmanaged off-heap (native) memory beyond the container size the job can fail because the deployment environment can kill the offending containers. {{< /hint >}} See also description of failure. This is only relevant for TaskManagers. When deploying a Flink streaming application, the type of used will dictate the optimal memory configurations of your cluster. When running a stateless job or using the ), set to zero. This will ensure that the maximum amount of heap memory is allocated for user code on the JVM. The uses native memory. By default, RocksDB is set up to limit native memory allocation to the size of the . Therefore, it is important to reserve enough managed memory for your state. If you disable the default RocksDB memory control, TaskManagers can be killed in containerized deployments if RocksDB allocates memory above the limit of the requested container size (the ). See also and . This is only relevant for TaskManagers. Flink's batch operators leverage to run more efficiently. In doing so, some operations can be performed directly on raw data without having to be deserialized into Java objects. This means that configurations have practical effects on the performance of your applications. Flink will attempt to allocate and use as much as configured for batch jobs but not go beyond its limits. This prevents `OutOfMemoryError`'s because Flink knows precisely how much memory it has to leverage. If the is not sufficient, Flink will gracefully spill to disk.