补充了个附录（https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh ）正常任务和异常任务的window算子的FlameGraph，不清楚是否有参考价值。
yidan zhao <[email protected]> 于2021年8月26日周四 下午1:01写道： > 目前来看，我运行6小时，window总计才收到200MB数据，这个数据量级相比我很多小到没有一样。所以很难想象反压的原因是啥究竟。 > > 目前来看反压节点的outPoolUsage是1，看起来合理，因为处于100%反压。 > 下游节点的inPoolUsage却是0，这个也很奇怪，同时下游buzz和backpress都是0%. > > > > Shengkai Fang <[email protected]> 于2021年8月26日周四 下午12:33写道： > >> - 得看一下具体的卡死的节点的栈，分析下具体的工作任务才知道。 >> - 日志中有包含错误的信息吗？ >> >> Best, >> Shengkai >> >> yidan zhao <[email protected]> 于2021年8月26日周四 下午12:03写道： >> >> > 可能存在机器压力倾斜，但是我是不太清楚这种现象的原因，直接停滞了任务？ >> > >> > 东东 <[email protected]> 于2021年8月26日周四 上午11:06写道： >> > >> > > 建议检查一下是否有数据倾斜 >> > > >> > > >> > > 在 2021-08-26 10:22:54，"yidan zhao" <[email protected]> 写道： >> > > >问题期间的确ckpt时间较长。 >> > > >但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 >> > > > >> > > >Caizhi Weng <[email protected]> 于2021年8月26日周四 上午10:20写道： >> > > > >> > > >> Hi！ >> > > >> >> > > >> 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ >> > > >> >> > > >> yidan zhao <[email protected]> 于2021年8月26日周四 上午10:09写道： >> > > >> >> > > >> > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 >> > > >> > >> > > >> > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh >> > > >> > >> > > >> >> > > >> > >> >
