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