flink-release-1.7.2/flink-dist/src/main/resources/flink-conf.yaml
Flink社区在FLIP-49提出了新版统一的TaskManager内存模型及配置，这也是Flink 1.10版本最主要的改进与优化点之一。根据社区的说法，该proposal致力于解决1.9版本及之前的TM内存配置的三个缺点：
flink-core-1.7.2-sources.jar!/org/apache/flink/configuration/TaskManagerOptions.java
本文主要研究一下flink的NetworkEnvironmentConfiguration
该作业启动了10个TaskManager，并正常运行。来到该任务的Web界面，随便打开一个TaskManager页面，看看它的内存情况。
Hi，我是王知无，一个大数据领域的原创作者。 先上一张官方给出的Flink(1.10版本以后)内存模型图示：
Apache Flink通过严格控制其各种组件的内存使用，在JVM之上提供高效的工作负载。
Flink 使用内存 = 框架堆内和堆外内存 + Task堆内和堆外内存 + 网络缓冲内存 + 管理内存。
那么如果设置了 -yjm 1024 ，JobManager的JVM的堆内存大小是多少呢？
在 Flink 1.12.0 版本中对 UI 进行了改进,在 TM 的页面增加了一个内存模型图,清楚的显示了每个区域的内存配置以及使用情况.
本文参考Flink1.10官方多篇文章相关知识收集、翻译、整合和内化而写成的关于Flink内存模型详解的文章，其中Job Manager、Task Manager和Client 分别是什么，各自之间的运行关系怎样，任务运行过程中所使用任务槽和资源情况的内存模型构成详解，内存设置需要配置哪些参数，参数功能描述等。暂时不熟悉Flink相关概念的童鞋自觉查阅笔者以往分享关于Flink术语基本概念的文章链接：Flink优化器与源码解析系列--Flink相关基本概念。
在大数据处理领域，Apache Flink以其流处理和批处理一体化的能力，成为许多企业的首选。然而，随着数据量的增长，性能优化变得至关重要。本文将深入浅出地探讨Flink SQL的常见性能问题、调优方法、易错点及调优技巧，并提供代码示例。
先来看一下官网上对flink内存设置的介绍。Flink JVM 进程的进程总内存（Total Process Memory）包含了由 Flink 应用使用的内存（Flink 总内存）以及由运行 Flink 的 JVM 使用的内存。Flink 总内存（Total Flink Memory）包括 JVM 堆内存（Heap Memory）和堆外内存（Off-Heap Memory）。其中堆外内存包括直接内存（Direct Memory）和本地内存（Native Memory）。
Tech 导读 本文综合Apache Flink原理与京东实时计算平台（JRC）的背景，详细讲述了大规模Flink流作业的调优方法。通过阅读本文，读者可了解Flink流作业的通用调优措施，并应用于生产环境。 写在前面 Apache Flink作为Google Dataflow Model的工业级实现，经过多年的发展，如今已经成为流式计算开源领域的事实标准。它具有高吞吐、低时延、原生流批一体、高一致性、高可用性、高伸缩性的特征，同时提供丰富的层级化API、时间窗口、状态化计算等语义，方便用户快速入门实时开发，
某用户反馈，Flink（版本1.9）任务中断，查看日志发现用户使用的是Flink on yarn，错误日志提示如下：
Apache Flink 基于 JVM 的高效处理能力，依赖于其对各组件内存用量的细致掌控。 考虑到用户在 Flink 上运行的应用的多样性，尽管社区已经努力为所有配置项提供合理的默认值，仍无法满足所有情况下的需求。 为了给用户生产提供最大化的价值， Flink 允许用户在整体上以及细粒度上对集群的内存分配进行调整。
从大的方面来说，TaskManager进程的内存模型分为JVM本身所使用的内存和Flink使用的内存，Flink使用了堆上内存和堆外内存。
【Flink】第四篇：【迷思】对update语义拆解D-、I+后造成update原子性丢失 【Flink】第五篇：checkpoint【1】 【Flink】第五篇：checkpoint【2】 【Flink】第八篇：Flink 内存管理 【Flink】第九篇：Flink SQL 性能优化实战 【Flink】第十篇：join 之 regular join 【Flink】第十三篇：JVM思维导图 【Flink】第十四篇：LSM-Tree一般性总结 【Flink】第十五篇：Redis Connector 数据保序思
Flink 的新版内存管理机制，要追溯到 2020 年初发布的 Flink 1.10 版本。当时 Flink 社区为了实现三大目标：
作者：董伟柯，腾讯 CSIG 高级工程师 概要 Flink 的新版内存管理机制，要追溯到 2020 年初发布的 Flink 1.10 版本。当时 Flink 社区为了实现三大目标： 流和批模式下内存管理的统一，即同一套内存配置既可用于流作业也可用于批作业 管控好 RocksDB 等外部组件的内存，避免在容器环境下用量不受控导致被 KILL 消除不同部署模式下配置参数的歧义，消除 cut-off 等参数语义模糊的问题 提出了两个设计提案 FLIP-49: Unified Memory Configuratio
在大数据领域我们都知道，开发是最简单，任务的合理调优、问题排查才是最重要的。我们在之前的文章《Flink面试通关手册》中也讲解过，作者结合线上出现的一些问题，总结了一些任务调优需要注意的点。
flink 的安装参照：flink 简单入门， 我们来了解下flink的配置文件。
Java 虚拟机在执行Java程序的过程中会把它在主存中管理的内存部分划分成多个区域，每个区域存放不同类型的数据。下图所示为java虚拟机运行的时候，主要的内存分区：
ack 数据源是否需要kafka得到确认。all表示需要收到所有ISR节点的确认信息，1表示只需要收到kafka leader的确认信息，0表示不需要任何确认信息。该配置项需要对数据精准性和延迟吞吐量做出权衡。
我们在Flink重点难点：状态(Checkpoint和Savepoint)容错与两阶段提交一文中对Flink的Checkpoint做过详细的介绍。
在Spark中有DataFrame这样的关系型编程接口，因其强大且灵活的表达能力，能够让用户通过非常丰富的接口对数据进行处理，有效降低了用户的使用成本。Flink也提供了关系型编程接口Table API以及基于Table API的SQL API，让用户能够通过使用结构化编程接口高效地构建Flink应用。同时Table API以及SQL能够统一处理批量和实时计算业务，无须切换修改任何应用代码就能够基于同一套API编写流式应用和批量应用，从而达到真正意义的批流统一
http://192.168.123.156:8088/cluster/scheduler
前段时间，某客户的大作业（并行度 200 左右）遇到了 TaskManager JVM 内存超限（实际内存用量 4.1G > 容器设定的最大阈值 4.0G），被 YARN 的 pmem-check 机制检测到并发送了 SIGTERM（kill）信号终止，最终导致作业出现崩溃。这个问题近期出现了好几次，客户希望能找到解决方案，避免国庆期间线上业务受到影响。
作者：董伟柯，腾讯 CSIG 高级工程师 问题背景 前段时间，某客户线上运行的大作业（并行度 200 左右）遇到了 TaskManager JVM 内存超限问题（实际内存用量 4.1G > 容器设定的最大阈值 4.0G），被 YARN 的 pmem-check 机制检测到并发送了 SIGTERM（kill）信号终止该 container，最终导致作业出现崩溃。这个问题近期出现了好几次，客户希望能找到解决方案，避免国庆期间线上业务受到影响。 在 Flink 配置项中，提供了很多内存参数设定。我们逐一检查了客户
自从2003-2006年，Google发表了三篇著名的大数据相关论文（Google FS，MapReduce，Big Table）后，内存问题一直困扰大数据工程师们。
流处理应用程序通常是有状态的，“记住”已处理事件的信息，并使用它来影响进一步的事件处理。在Flink中，记忆的信息（即状态）被本地存储在配置的状态后端中。为了防止发生故障时丢失数据，状态后端会定期将其内容快照保存到预先配置的持久性存储中。该RocksDB[1]状态后端（即RocksDBStateBackend）是Flink中的三个内置状态后端之一。这篇博客文章将指导您了解使用RocksDB管理应用程序状态的好处，解释何时以及如何使用它，以及清除一些常见的误解。话虽如此，这不是一篇说明RocksDB如何深入工作或如何进行高级故障排除和性能调整的博客文章；如果您需要任何有关这些主题的帮助，可以联系Flink用户邮件列表[2]。
Flink是一个有状态的流式计算引擎，所以会将中间计算结果（状态）进行保存，默认保存到TaskManager的堆内存中。
作者：董伟柯，腾讯云大数据高级工程师 概要 我们知道，旧版本 Flink 的 JobManager 作为管理者，只承担着初始化和协调的任务，内存压力非常小，很少出现 OOM 等问题。 但是，随着 Flink CDC [1] 实时数据捕获技术的广泛应用，以及采用 Flink 新版 Source 接口（FLIP-27: Refactor Source Interface [2]）的 Connector 日渐增加，JobManager 的职责越来越重：它还肩负着定期动态感知和协调数据分片的职责（SplitEnum
我们知道，旧版本 Flink 的 JobManager 作为管理者，只承担着初始化和协调的任务，内存压力非常小，很少出现 OOM 等问题。
Flink是一个有状态的流式计算引擎，所以会将中间计算结果(状态)进行保存，默认保存到TaskManager的堆内存中，但是当task挂掉，那么这个task所对应的状态都会被清空，造成了数据丢失，无法保证结果的正确性，哪怕想要得到正确结果，所有数据都要重新计算一遍，效率很低。想要保证 At -least-once 和 Exactly-once，需要把数据状态持久化到更安全的存储介质中，Flink提供了堆内内存、堆外内存、HDFS、RocksDB等存储介质。
本文主要研究一下flink taskmanager的data.port与rpc.port
TaskManager 是工作节点，负责数据交换，跑多个线程的 task，执行任务。
自从写 Flink 系列文章，收到了太多读者的私信，希望我不断更新完善 Flink 专栏，为此，土哥还专门创建了一个文档，用来记录粉丝和读者在使用 Flink 组件时遇到的典型问题。
Kubernetes 是一种流行的容器编排系统，用于自动化计算机应用程序的部署、扩展和管理。 Flink 的原生 Kubernetes 集成允许您直接在运行的 Kubernetes 集群上部署 Flink。 此外，Flink 能够根据所需资源动态分配和取消分配 TaskManager，因为它可以直接与 Kubernetes 对话。
为了解决Flink作业使用RocksDB状态后端时的内存超用问题，Flink早在1.10版本就实现了RocksDB的托管内存(managed memory)机制。用户只需启用state.backend.rocksdb.memory.managed参数(默认即为true)，再设定合适的TaskManager托管内存比例taskmanager.memory.managed.fraction，即可满足多数情况的需要。
Flink的Slot概念大家应该都听说过，但是可能很多朋友还不甚了解其中细节，比如具体Slot究竟代表什么？在代码中如何实现？Slot在生成执行图、调度、分配资源、部署、执行阶段分别起到什么作用？本文和下文将带领大家一起分析源码，为你揭开Slot背后的机理。
首先我们可以看下这张最精简的网络流控的图，Producer 的吞吐率是 2MB/s，Consumer 是 1MB/s，这个时候我们就会发现在网络通信的时候我们的 Producer 的速度是比 Consumer 要快的，有 1MB/s 的这样的速度差，假定我们两端都有一个 Buffer，Producer 端有一个发送用的 Send Buffer，Consumer 端有一个接收用的 Receive Buffer，在网络端的吞吐率是 2MB/s，过了 5s 后我们的 Receive Buffer 可能就撑不住了，这时候会面临两种情况：
我们在系列文章第一篇已经为大家介绍了 Flink 的基本概念以及安装部署的过程，希望能够帮助读者建立起对 Flink 的初步印象。这是系列文章第二篇，主要面向于初次接触 Flink 或者对 Flink 有了解但是没有实际操作过的同学。希望帮助大家更顺利地上手使用 Flink，并着手相关开发调试工作。
昨天，分析修复了一个connector的问题。下面开始陈述整个过程，依旧按照之前的陈述思路进行：
在一个企业中，为了最大化的利用集群资源，一般都会在一个集群中同时运行多种类型的 Workload。因此 Flink 也支持在 Yarn 上面运行。首先，让我们了解下 Yarn 和 Flink 的关系。
上一篇聊到flink的历史，请看上篇 flink两三事 ----（1）历史。 可以说基本上是起了个大早，赶了个晚集，但是flink能做今天这种热度，没有被spark干死也是不容易。原来大家都在想办法突破MapReduce太慢的问题时候，除了spark，比如还有Tez等框架基本上销声匿迹了。14年flink在apache孵化能活下来并成为顶级项目的关键还是flink的有些自己的创新技术。 Spark的核心概念是RDD，抽象概念是弹性分布式数据集(RDD)，它是一个元素集合，划分到集群的各个节点上，可以被并行操
本文主要研究一下flink taskmanager的jvm-exit-on-oom配置
Apache Flink 是一个开源的流处理和批处理框架，具有高吞吐量、低延迟的流式引擎，支持事件时间处理和状态管理，以及确保在机器故障时的容错性和一次性语义。Flink 的核心是一个分布式流数据处理引擎，支持 Java、Scala、Python 和 SQL 编程语言，可以在集群或云环境中执行数据流程序。它提供了 DataStream API 用于处理有界或无界数据流，DataSet API 用于处理有界数据集，以及 Table API 和 SQL 接口用于关系型流和批处理。目前 Flink 最新已经迭代至 1.20 版本，在此过程中不光是 Flink 框架，插件本身也有部分 API 以及配置存在变更，本文主要针对较高版本的 1.17 Flink Pulsar 插件进行测试验证，目前 Flink 版本如下：https://nightlies.apache.org/flink/
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
