Hi Yang 数据倾斜严重的task处理数据比较慢，barrier很可能卡在了channel里面，导致task一直无法收到barrier触发该task上的checkpoint。这也与你观察到的现象一致（sync+async的时间很短）。 数据倾斜情况下，无论哪种state backend都会比较吃力。FsStateBackend在不发生GC的情况下，性能是要优于RocksDB的，如果只是简单的切换state backend，也应该考虑将RocksDB使用的managed memory转移到JVM heap上，建议观察一下GC日志，是否存在频繁的GC和Full GC。
如果不存在明显的JVM heap内存问题，主要就是要考虑如何优化数据倾斜。 祝好 唐云 ________________________________ From: Yang Peng <yangpengklf...@gmail.com> Sent: Monday, August 10, 2020 17:37 To: user-zh <user-zh@flink.apache.org> Subject: Re: Flink任务大状态使用filesystem反压 感谢唐云老师，任务的确是存在一定的数据倾斜，执行cp时间比较久是因为其中一个subtask执行cp的时间太久了主要是end-to-end时间长 而且这个subtask就是数据倾斜比较严重的task，我测试的时候重启任务都是从最新的offset重启的是随着每次执行cp时间越来越长，监控上显示kafkasource端日志堆积越来越大，但是相同的代码只是修改了statebackend为rocksdb 就不存在这种问题，所以很奇怪为什么用的内存反而不如rocksdb了 Yun Tang <myas...@live.com> 于2020年8月10日周一 下午4:21写道： > Hi Yang > > checkpoint执行时间长，具体是同步阶段还是异步阶段长呢，亦或是同步+异步时间不长但是end-to-end 时间长呢？ > 如果是异步阶段时间长，一般是因为使用的DFS性能较差。 > 如果各个阶段时间均不长，但是总体时间很长，很有可能还是因为反压（如果启用了exactly once > checkpoint，可以观察是否buffered的数据很多） > > > kafka数据源积压的数据多，不就是说明source端存在延迟么，这种说明整体作业还是处于反压的状态，需要定位一下究竟是哪里在反压，不一定与使用FsStateBackend有直接关系。 > > 祝好 > 唐云 > ________________________________ > From: Yang Peng <yangpengklf...@gmail.com> > Sent: Monday, August 10, 2020 15:55 > To: user-zh <user-zh@flink.apache.org> > Subject: Flink任务大状态使用filesystem反压 > > Hi，咨询各位一个问题，我们线上任务使用rocksdb作为statebackend > > 时间久了发现会出现反压，查看服务器监控发现机器io经常是满的，为了保证业务稳定性，现在将statebackend改为filesystem，但是发现已经配置了很大的内存，使用filesystem之后执行cp时间特别长，而且kafka数据源积压很大，大家有遇到这种情况的吗？是使用filesystem的姿势不对吗？ >
