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的姿势不对吗? >