Apache flink 使用RocksDB状态后端检查Flink 1.10.1中的问题

我们的Flink工作遇到了一个很难观察到的问题

这项工作相当简单，它：

使用Flink Kinesis连接器从Kinesis读取消息

键入消息并将其分发给约30个不同的CEP操作员，以及两个自定义的WindowFunction

从CEP/Windows发出的消息被转发到将消息写入SQS的SinkFunction

我们正在运行Flink 1.10.1 Fargate，使用2个4vCPU/8GB的容器，我们正在使用RocksDB状态后端，配置如下：

state.backend: rocksdb
state.backend.async: true
state.backend.incremental: false
state.backend.rocksdb.localdir: /opt/flink/rocksdb
state.backend.rocksdb.ttl.compaction.filter.enabled: true
state.backend.rocksdb.files.open: 130048

state.backend.rocksdb.checkpoint.transfer.thread.num: {threadNumberAccordingYourProjectSize}

作业以8的并行度运行

当作业从冷启动时，它使用很少的CPU，检查点在2秒内完成。随着时间的推移，检查点的大小会增加，但时间仍然是非常合理的几秒钟：

在此期间，我们可以观察到TaskManager的CPU使用率由于某些原因而缓慢增长：

最终，检查点时间将开始增加到几分钟，然后将开始反复超时（10分钟）。此时：

• 检查点大小（完成时）约为60MB
• CPU使用率很高，但不是100%（通常在60-80%左右）
• 查看正在进行的检查点，通常95%以上的操作员会在30秒内完成检查点，但少数人会坚持，永远不会完成。SQS接收器将始终包含在其中，但

  SinkFunction

  不丰富且没有状态
• 在这些操作员上使用背压监测器报告背压高

最终，这种情况解决了以下两种方法之一：

由于检查点比例阈值失败，有足够多的检查点无法触发作业失败

检查点最终开始成功，但不会回到最初的5-10秒（当状态大小更像30MB而不是60MB时）

我们真的不知道如何调试它。与你在这里的一些问题中看到的国家相比，我们的国家似乎非常小。我们的流量也很低，通常低于100条记录/秒

我们非常感谢您对我们可以进行调试的领域的任何意见

谢谢，有几点：

随着时间的推移，这种状态逐渐增长是很正常的。也许您的密钥空间正在增长，并且您正在为每个密钥保持一些状态。如果您依赖于状态TTL使过期状态过期，可能它的配置方式不允许它像您期望的那样快速清除过期状态。在排除某些可能的匹配之前，不经意地创建CEP模式也相对容易，这些模式需要在很长时间内保持某种状态

下一步是确定背压的原因。最常见的原因是作业没有足够的资源。随着时间的推移，随着被管理的用户数量（例如）的增加，大多数作业逐渐需要更多的资源。例如，您可能需要增加并行性，或为实例提供更多内存，或增加接收器的容量（或接收器的网络速度），或为RocksDB提供更快的磁盘

除了供应不足外，造成背压的其他原因包括

• 正在用户函数中执行阻塞i/o
• 大量计时器同时启动
• 不同源之间的事件时间偏差导致大量状态被缓冲
• 数据倾斜（热键）压倒了一个子任务或插槽
• 冗长的GC暂停
• 争夺关键资源（例如，使用NAS作为RocksDB的本地磁盘）

---

启用可能会提供一些见解。

将此属性添加到配置中：

state.backend: rocksdb
state.backend.async: true
state.backend.incremental: false
state.backend.rocksdb.localdir: /opt/flink/rocksdb
state.backend.rocksdb.ttl.compaction.filter.enabled: true
state.backend.rocksdb.files.open: 130048

state.backend.rocksdb.checkpoint.transfer.thread.num: {threadNumberAccordingYourProjectSize}

如果不添加此项，则它将为1（默认值）

---

链接：

您是否使用状态TTL，如果是，它是如何配置的？