感谢唐云老师，任务的确是存在一定的数据倾斜，执行cp时间比较久是因为其中一个subtask执行cp的时间太久了主要是end-to-end时间长 而且这个subtask就是数据倾斜比较严重的task，我测试的时候重启任务都是从最新的offset重启的是随着每次执行cp时间越来越长，监控上显示kafkasource端日志堆积越来越大，但是相同的代码只是修改了statebackend为rocksdb 就不存在这种问题，所以很奇怪为什么用的内存反而不如rocksdb了
Yun Tang <[email protected]> 于2020年8月10日周一 下午4:21写道： > Hi Yang > > checkpoint执行时间长，具体是同步阶段还是异步阶段长呢，亦或是同步+异步时间不长但是end-to-end 时间长呢？ > 如果是异步阶段时间长，一般是因为使用的DFS性能较差。 > 如果各个阶段时间均不长，但是总体时间很长，很有可能还是因为反压（如果启用了exactly once > checkpoint，可以观察是否buffered的数据很多） > > > kafka数据源积压的数据多，不就是说明source端存在延迟么，这种说明整体作业还是处于反压的状态，需要定位一下究竟是哪里在反压，不一定与使用FsStateBackend有直接关系。 > > 祝好 > 唐云 > ________________________________ > From: Yang Peng <[email protected]> > Sent: Monday, August 10, 2020 15:55 > To: user-zh <[email protected]> > Subject: Flink任务大状态使用filesystem反压 > > Hi，咨询各位一个问题，我们线上任务使用rocksdb作为statebackend > > 时间久了发现会出现反压，查看服务器监控发现机器io经常是满的，为了保证业务稳定性，现在将statebackend改为filesystem，但是发现已经配置了很大的内存，使用filesystem之后执行cp时间特别长，而且kafka数据源积压很大，大家有遇到这种情况的吗？是使用filesystem的姿势不对吗？ >
