Hi FsStateBackend 在性能上是比 RocksDBStateBackend 好，这个是符合预期的。不过想要获得高性能的话，需要更多的jvm堆上内存，但是大内存场景下的GC会很痛苦，所以并不是说加内存之后，性能可以线性增长。
现在还有一个问题是你的状态有多大呢，可以去有状态的节点上看DB的大小（通过增量checkpoint的checkpointed data size也可以间接推出），看CPU使用情况，看磁盘的iostat，来找到具体的瓶颈在哪里。 祝好 唐云 ________________________________ From: Jark Wu <[email protected]> Sent: Thursday, December 10, 2020 11:04 To: user-zh <[email protected]> Cc: Yun Tang <[email protected]> Subject: Re: 关于flink cdc的N流join状态后端的选择问题： FsStateBackend和RocksDBStateBackend 关于 rocksdb 的性能调优, @Yun Tang<mailto:[email protected]> 会更清楚。 On Thu, 10 Dec 2020 at 11:04, Jark Wu <[email protected]<mailto:[email protected]>> wrote: 建议大状态还是用 rocksdb，生产上会稳定很多。你说的这个量级感觉相差比较大，可能还没有对 rocksdb 调优导致的。 你可以参考下这几篇文章尝试调优下 rocksdb： https://mp.weixin.qq.com/s/YpDi3BV8Me3Ay4hzc0nPQA https://mp.weixin.qq.com/s/mjWGWJVQ_zSVOgZqtjjoLw https://mp.weixin.qq.com/s/ylqK9_SuPKBKoaKmcdMYPA https://mp.weixin.qq.com/s/r0iPPGWceWkT1OeBJjvJGg Best, Jark On Wed, 9 Dec 2020 at 12:19, jindy_liu <[email protected]<mailto:[email protected]>> wrote: 场景上： 目前都是mysql里的带主键的表（亿级别）的join操作后，得到的实时宽表（视图)上做一些规则筛选或计数等，并且场景上状态（join算子）都基上上不设置TTL。 目前mysql中的都是些有主键数据，且量级不会有太大的变化，并且可以预见，可能一年也就增加个200w左右，但表里的数据变更较频繁。所以处理上需要吞吐量较大，延时低。 目前测试了一版本flink sql算子使用Rocksdb做后端发现吞吐与延时都比较大，一条数据变化，可能要10秒中才能生效，但换FsStateBackend时，速度就很快了，性能较好；两者相差10倍多。 所以产生以下想法，不知道可不可行？ 1、用FsStateBackend：想堆机器，把任务里的用到的状态都用FsStateBackend放内存来搞（基于表的主键数有限，状态应该也是有限的）。 2、还用rocksdb：尽量把flink的manager内存（rocksdb用的）搞得较大，把读写rocksdb都尽量在内存中进行。 目前对flink sql生成的算子的状态情况不太熟悉，想问题下这两种方法是否可行呢？ -- Sent from: http://apache-flink.147419.n8.nabble.com/
