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

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