Flink taskmanager内存和内存配置不足

Question

我们正在使用Flink流在单个群集上运行一些作业。我们的工作是使用rocksDB来建立一个州。 群集配置为在3个独立的VM上使用单个Jobmanager和3 Taskmanager运行。 每个TM都配置为使用14GB的RAM运行。 JM配置为以1GB运行。

我们遇到了2个与内存相关的问题： - 当运行具有8GB堆分配的Taskmanager时，TM耗尽了堆内存，我们得到了堆内存异常。我们解决这个问题的方法是将堆大小增加到14GB。似乎这种配置解决了这个问题，因为我们不会因堆内存不足而崩溃。 - 仍然，在将堆大小增加到14GB（每个TM进程）后，操作系统内存不足并导致TM进程终止。 RES存储器随着时间的推移而上升，每个TM进程达到~20GB。

1。问题是我们如何预测物理内存和堆大小配置的最大总量？

2。由于我们的内存问题，使用Flink托管内存的非默认值是否合理？这种情况下的指导原则是什么？

进一步详情： 每个Vm配置有4个CPU和24GB RAM 使用Flink版本：1.3.2

Answer 1

所需的物理内存和堆内存总量非常难以计算，因为它很大程度上取决于您的用户代码，作业的拓扑以及您使用的后端状态。

根据经验，如果您遇到OOM但仍在使用FileSystemStateBackend或MemoryStateBackend，那么您应该切换到RocksDBStateBackend，因为它可以优雅地溢出到磁盘上国家变得太大了。

如果您仍然遇到OOM异常，那么您应该检查您的用户代码是保留对状态对象的引用还是以其他方式生成无法进行垃圾回收的大型对象。如果是这种情况，那么你应该尝试重构你的代码以依赖Flink的状态抽象，因为使用RocksDB它可以脱离核心。

RocksDB本身需要本机内存，这会增加Flink的内存占用。这取决于块缓存大小，索引，布隆过滤器和memtables。您可以找到有关这些内容的更多信息以及如何配置它们here。

最后但并非最不重要的一点是，在运行流式传输作业时不应激活taskmanager.memory.preallocate，因为流式传输作业目前不使用托管内存。因此，通过激活预分配，您将为Flink的托管内存分配内存，这会减少可用的堆空间。

Answer 2

使用RocksDBStateBackend可能会导致大量的堆外/直接内存消耗，直至主机上的可用内存。通常，当任务管理器进程是唯一的大内存使用者时，这不会造成问题。但是，如果存在其他进程具有动态更改的内存分配，则可能导致内存不足。我正在寻找这篇文章，因为我正在寻找一种限制RocksDBStateBackend内存使用量的方法。从Flink 1.5开始，here有可用的替代选项集。看来这些只能通过编程方式激活，而不能通过flink-conf.yaml来激活。