我们使用 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 托管内存的非默认值是否合理？在这种情况下，指导方针是什么？
更多细节：
每个虚拟机配置有 4 个 CPU 和 24GB RAM
使用Flink版本：1.3.2
所需的物理内存和堆内存的总量非常难以计算，因为它很大程度上取决于您的用户代码、作业的拓扑以及您使用的状态后端。
根据经验，如果您遇到 OOM 并且仍在使用FileSystemStateBackend or the MemoryStateBackend，那么你应该切换到RocksDBStateBackend，因为如果状态变得太大，它可以优雅地溢出到磁盘。
如果您仍然遇到如上所述的 OOM 异常，那么您应该检查您的用户代码是否保留对状态对象的引用或以其他方式生成无法被垃圾收集的大对象。如果是这种情况，那么您应该尝试重构代码以依赖 Flink 的状态抽象，因为使用 RocksDB 它可能会脱离核心。
RocksDB 本身需要本机内存，这增加了 Flink 的内存占用。这取决于块缓存大小、索引、布隆过滤器和内存表。您可以了解有关这些内容以及如何配置它们的更多信息here https://github.com/facebook/rocksdb/wiki/Memory-usage-in-RocksDB.
最后但并非最不重要的一点是，您不应该激活taskmanager.memory.preallocate运行流作业时，因为流作业当前不使用托管内存。因此，通过激活预分配，您将为 Flink 的托管内存分配内存，这会减少可用的堆空间。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
