Flink taskmanager out of memory 和内存配置

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 的内存占用。这取决于块缓存大小、索引、布隆过滤器和内存表。您可以通过here了解更多关于这些内容以及如何配置它们的信息。

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

Answer 2

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