我现在flink服务启动之后，占用的cpu有点多，20%-30%。服务器是64核的。这样正常吗？[阿里云实时计算 Flink版] 暂停朗读为您朗读

不正常，可以尝试调大 bufferTimeout 参数来优化。

在Flink中你可以设置要使用的最大内存和任务槽的数量（它只是划分内存）。 taskmanager.numberOfTaskSlots：单个TaskManager可以运行的并行操作符或用户函数实例的数量（默认值：1）。如果此值大于1，则单个TaskManager将获取函数或运算符的多个实例。这样，TaskManager可以使用多个CPU内核，但同时，可用内存在不同的操作员或功能实例之间划分 。该值通常与TaskManager的机器具有的物理CPU核心数成比例（例如，等于核的数量，或核的数量的一半）。 同时Flink大并发任务（超过500并发）在使用keyBy或者rebalance的情况下，将 bufferTimeout设置为1s可以节省30~50%的CPU消耗。

由于使用的是基于堆的状态后端( FSStateBackend将其工作状态保留在JVM堆上)，并且状态TTL被配置为1(或3)天，因此可以预期状态大小将会增长。它将增长多少是特定于应用程序的；它取决于密钥空间如何随着时间的推移而增长。 检查点变慢的原因有很多，但通常这表明在到达远程文件系统时存在反压力或某种类型的资源争用–即S3速率限制。如果您在Flink WebUI中查看检查点统计信息，您可以在那里查找线索。查看检查点是否会占用很长时间来遍历执行图，或者检查点的异步部分是否需要很长时间才能将检查点写入远程磁盘。寻找不对称性–一个实例是否比其他实例花费的时间更长在用户函数中执行任何阻塞i/o操作，这可能会带来麻烦。或者你可能有严重的数据偏差(例如，热键)。或者任务管理器和分布式文件系统之间的慢速网络。或者集群可能配置不足–您可能需要增加并行度。 可能需要增加检查点超时。如果在某个时候检查点持续时间真的变得有问题，您可以切换到使用RocksDB状态后端，以便能够使用增量检查点(但这是否会有所帮助取决于正在发生的事情)。或者，可以更快地将状态TTL配置更改为清除状态。