MemoryManager

相信不少读者在开发 Flink 应用时或多或少会遇到在内存调优方面的问题，比如在我们生产环境中遇到最多的 TaskManager 在容器化环境下占用超出容器限制的内存而被 YARN/Mesos kill 掉[1]，再比如使用 heap-based StateBackend 情况下 State 过大导致 GC 频繁影响吞吐。这些问题对于不熟悉 Flink 内存管理的用户来说十分难以排查，而且 Flink 晦涩难懂的内存配置参数更是让用户望而却步，结果是往往将内存调大至一个比较浪费的阈值以尽量避免内存问题。 对于作业规模不大的普通用户而言，这些通常在可以接受的范围之内，但对于上千并行度的大作业来说，浪费资源的总量会非常可观，而且进程的不稳定性导致的作业恢复时间也会比普通作业长得多，因此阿里巴巴的 Blink 团队针对内存管理机制做了大量的优化，并于近期开始合并到 Flink。本文的内容主要基于阿里团队工程师宋辛童在 Flink Forward Beijing 的分享[2]，以及后续相关的几个 FLIP 提案。 Flink 目前（1.9）的内存管理 TaskManager 作为 Master/Slave 架构中的 Slave 提供了作业执行需要的环境和资源，最为重要而且复杂，因此 Flink 的内存管理也主要指 TaskManager 的内存管理。 TaskManager 的资源

相信不少读者在开发 Flink 应用时或多或少会遇到在内存调优方面的问题，比如在我们生产环境中遇到最多的 TaskManager 在容器化环境下占用超出容器限制的内存而被 YARN/Mesos kill 掉[1]，再比如使用 heap-based StateBackend 情况下 State 过大导致 GC 频繁影响吞吐。这些问题对于不熟悉 Flink 内存管理的用户来说十分难以排查，而且 Flink 晦涩难懂的内存配置参数更是让用户望而却步，结果是往往将内存调大至一个比较浪费的阈值以尽量避免内存问题。 对于作业规模不大的普通用户而言，这些通常在可以接受的范围之内，但对于上千并行度的大作业来说，浪费资源的总量会非常可观，而且进程的不稳定性导致的作业恢复时间也会比普通作业长得多，因此阿里巴巴的 Blink 团队针对内存管理机制做了大量的优化，并于近期开始合并到 Flink。本文的内容主要基于阿里团队工程师宋辛童在 Flink Forward Beijing 的分享[2]，以及后续相关的几个 FLIP 提案。 Flink 目前（1.9）的内存管理 TaskManager 作为 Master/Slave 架构中的 Slave 提供了作业执行需要的环境和资源，最为重要而且复杂，因此 Flink 的内存管理也主要指 TaskManager 的内存管理。 TaskManager 的资源

摘要 Borland Object Pascal 对象模型（现在已经正是命名为 Delphi 语言）与其他 OOP 语言一样，都提供了一些基础服务： 如对象创建服务、对象释放服务、对象识别服务、对象信息服务，除此之外在编译器和 VCL framework 级别上提供了一些额外的服务，例如对象消息分派服务。 前言 　　首先说一下，Delphi 对象模型涉及的概念非常多，因此在这篇笔记中，我无法将所有的知识点都点到，只是理出一条线方便后来人。可以说这部分内容不是很容易搞懂的，建议大家多看 VCL 源码，它可真是一座金山，有你挖不完的金子，每次你都会有意外收获的。另外有些概念恐怕看源码也不见得搞得懂，这时候你可以通过 Debug 看看反汇编的结果，通常会看到编译器为你做了很多幕后工作。有了这种钻研精神，我想恐怕没有什么问题解决不了的。 正文 Delphi 中万物之源是 TObject，不管你自定义的类是否指明了所继承的父类，一定都是 TObject 的子孙，一样具有 TObject 定义的所有特性[3]。由于在 TObject 中已经提供了大部分的对象基础服务，因此继承类自然而然也就具备了这些对象服务，强烈建议每一个学 Delphi 的朋友都要仔细研习一下 TObject 的源码。 　　一个对象的生命周期是从它被创建那一刻开始。通常我们都用类似 TMyObject.Create

Delphi SuperDll 作为一名5年的Delpher，一直认为Delphi是桌面应用的王者，我相信其他的Delpher也这么认为。 但是，慢慢的我发现普通方式的Delphi开发会造成代码的严重臃肿，特别是MDI类大型项目、多人同时开发的情况下。 举个例子，一个Delphi常用的业务逻辑，数据导出到Excel，完全可以写成一个公用的模块放置在业务单元，子窗体用到时直接调用即可，但是一般情况下，事情并不止想象的那么简单，维护人员的思想真的一言难尽。 后来，我有了将Delphi中常用的业务逻辑功能封装成DLL的想法，所有的业务逻辑只能在DLL中实现，系统中不允许直接写业务逻辑，只能调用DLL。 这么做的好处是，相同的业务功能不会被重复开发，大大减少了代码的臃肿，同时，业务逻辑开发人员和前台开发人员独立开来，提高了开发效率。 这里就是SuperDLL的由来，后续将持续更新。 请看如下代码： 更新日志： //初始化 //邮件发送 //FTP上传、下载 //cxGrid数据导出 1 library SuperDll; 2 3 { Important note about DLL memory management: ShareMem must be the 4 first unit in your library's USES clause AND your project's

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 同事提供的flink项目，在他那边执行可以，在我这边报奇怪的错误，而且mq的source也没触发，报的错如下： java.lang.RuntimeException: Buffer pool is destroyed. at org.apache.flink.streaming.runtime.io.RecordWriterOutput.pushToRecordWriter(RecordWriterOutput.java:110) ~[flink-streaming-java_2.11-1.8.1.jar:1.8.1] at org.apache.flink.streaming.runtime.io.RecordWriterOutput.collect(RecordWriterOutput.java:89) ~[flink-streaming-java_2.11-1.8.1.jar:1.8.1] at org.apache.flink.streaming.runtime.io.RecordWriterOutput.collect(RecordWriterOutput.java:45) ~[flink-streaming-java_2.11-1.8.1.jar:1.8.1] at org.apache.flink

序 本文主要研究一下flink TaskManager的managed memory TaskManagerOptions flink-core-1.7.2-sources.jar!/org/apache/flink/configuration/TaskManagerOptions.java @PublicEvolving public class TaskManagerOptions { //...... /** * JVM heap size for the TaskManagers with memory size. */ @Documentation.CommonOption(position = Documentation.CommonOption.POSITION_MEMORY) public static final ConfigOption<String> TASK_MANAGER_HEAP_MEMORY = key("taskmanager.heap.size") .defaultValue("1024m") .withDescription("JVM heap size for the TaskManagers, which are the parallel workers of" + " the system. On YARN setups, this