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