我们使用flink流在单个集群上运行一些作业。我们的工作是用rocksdb来控制一个州。集群配置为在3个单独的vm上运行一个jobmanager和3个taskmanager。每个tm配置为使用14gb的ram运行。jm被配置为运行1gb。
我们遇到了两个与内存相关的问题：-在使用8gb堆分配运行taskmanager时，tm堆内存不足，出现堆内存不足异常。我们解决这个问题的方法是将堆大小增加到14gb。似乎这个配置解决了这个问题，因为我们不再因堆内存不足而崩溃。-尽管如此，在将堆大小增加到14gb（每个tm进程）之后，os会耗尽内存并杀死tm进程。随着时间的推移，res内存不断增加，每个tm进程的存储容量达到20gb左右。
1.问题是我们如何预测最大的物理内存总量和堆大小配置？
2.由于内存问题，使用flink托管内存的非默认值是否合理？在这种情况下，指导方针是什么？
更详细的信息：每个虚拟机使用flink版本1.3.2配置了4个cpu和24gb的ram
2条答案
按热度按时间shstlldc1#
所需的物理内存和堆内存总量很难计算，因为它在很大程度上取决于用户代码、作业的拓扑结构以及使用的后端状态。
根据经验，如果您遇到oom并且仍在使用
FileSystemStateBackend或者MemoryStateBackend，则应切换到RocksDBStateBackend，因为如果状态变得太大，它可以优雅地溢出到磁盘。如果您仍然遇到前面描述的oom异常，那么您应该检查您的用户代码是否保留对状态对象的引用，或者以其他方式生成无法垃圾收集的大型对象。如果是这样的话，那么您应该尝试重构代码以依赖于flink的状态抽象，因为使用rocksdb它可能会超出核心。
rocksdb本身需要本机内存，这增加了flink的内存占用。这取决于块缓存大小、索引、bloom过滤器和memtables。您可以在这里了解有关这些内容以及如何配置它们的更多信息。
最后但同样重要的是，你不应该激活
taskmanager.memory.preallocate当运行流作业时，因为流作业当前不使用托管内存。因此，通过激活预分配，您可以为flink的托管内存分配内存，从而减少可用堆空间。b09cbbtk2#
使用rocksdbstatebackend可能会导致大量堆外/直接内存消耗，直至主机上的可用内存。通常，当任务管理器进程是唯一的大内存使用者时，这不会导致问题。但是，如果有其他进程具有动态更改的内存分配，则可能会导致内存不足。我看到这篇文章是因为我在寻找一种方法来限制rocksdbstatebackend内存的使用。从flink 1.5开始，这里有其他选项集可用。但似乎这些只能通过编程方式激活，而不是通过
flink-conf.yaml.