Re: Flink任务假死；无限100%反压；但下游节点无压力。
可以看yuque里边哈，有DAG的。 JasonLee <17610775...@163.com> 于2021年8月26日周四 下午1:35写道： > Hi > > > 可以发一下任务的 DAG 吗 > > > Best > JasonLee > > > 在2021年08月26日 13:09，yidan zhao 写道： > 补充了个附录（https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh > ）正常任务和异常任务的window算子的FlameGraph，不清楚是否有参考价值。 > > yidan zhao 于2021年8月26日周四 下午1:01写道： > > 目前来看，我运行6小时，window总计才收到200MB数据，这个数据量级相比我很多小到没有一样。所以很难想象反压的原因是啥究竟。 > > 目前来看反压节点的outPoolUsage是1，看起来合理，因为处于100%反压。 > 下游节点的inPoolUsage却是0，这个也很奇怪，同时下游buzz和backpress都是0%. > > > > Shengkai Fang 于2021年8月26日周四 下午12:33写道： > > - 得看一下具体的卡死的节点的栈，分析下具体的工作任务才知道。 > - 日志中有包含错误的信息吗？ > > Best, > Shengkai > > yidan zhao 于2021年8月26日周四 下午12:03写道： > > 可能存在机器压力倾斜，但是我是不太清楚这种现象的原因，直接停滞了任务？ > > 东东 于2021年8月26日周四 上午11:06写道： > > 建议检查一下是否有数据倾斜 > > > 在 2021-08-26 10:22:54，"yidan zhao" 写道： > 问题期间的确ckpt时间较长。 > 但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 > > Caizhi Weng 于2021年8月26日周四 上午10:20写道： > > Hi！ > > 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ > > yidan zhao 于2021年8月26日周四 上午10:09写道： > > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 > > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh > > > > > > >
回复： Flink任务假死；无限100%反压；但下游节点无压力。
Hi 可以发一下任务的 DAG 吗 Best JasonLee 在2021年08月26日 13:09，yidan zhao 写道： 补充了个附录（https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh ）正常任务和异常任务的window算子的FlameGraph，不清楚是否有参考价值。 yidan zhao 于2021年8月26日周四 下午1:01写道： 目前来看，我运行6小时，window总计才收到200MB数据，这个数据量级相比我很多小到没有一样。所以很难想象反压的原因是啥究竟。 目前来看反压节点的outPoolUsage是1，看起来合理，因为处于100%反压。 下游节点的inPoolUsage却是0，这个也很奇怪，同时下游buzz和backpress都是0%. Shengkai Fang 于2021年8月26日周四 下午12:33写道： - 得看一下具体的卡死的节点的栈，分析下具体的工作任务才知道。 - 日志中有包含错误的信息吗？ Best, Shengkai yidan zhao 于2021年8月26日周四 下午12:03写道： 可能存在机器压力倾斜，但是我是不太清楚这种现象的原因，直接停滞了任务？ 东东 于2021年8月26日周四 上午11:06写道： 建议检查一下是否有数据倾斜 在 2021-08-26 10:22:54，"yidan zhao" 写道： 问题期间的确ckpt时间较长。 但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 Caizhi Weng 于2021年8月26日周四 上午10:20写道： Hi！ 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ yidan zhao 于2021年8月26日周四 上午10:09写道： 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh
Re: Re: Flink任务假死；无限100%反压；但下游节点无压力。
补充了个附录（https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh ）正常任务和异常任务的window算子的FlameGraph，不清楚是否有参考价值。 yidan zhao 于2021年8月26日周四 下午1:01写道： > 目前来看，我运行6小时，window总计才收到200MB数据，这个数据量级相比我很多小到没有一样。所以很难想象反压的原因是啥究竟。 > > 目前来看反压节点的outPoolUsage是1，看起来合理，因为处于100%反压。 > 下游节点的inPoolUsage却是0，这个也很奇怪，同时下游buzz和backpress都是0%. > > > > Shengkai Fang 于2021年8月26日周四 下午12:33写道： > >> - 得看一下具体的卡死的节点的栈，分析下具体的工作任务才知道。 >> - 日志中有包含错误的信息吗？ >> >> Best, >> Shengkai >> >> yidan zhao 于2021年8月26日周四 下午12:03写道： >> >> > 可能存在机器压力倾斜，但是我是不太清楚这种现象的原因，直接停滞了任务？ >> > >> > 东东 于2021年8月26日周四 上午11:06写道： >> > >> > > 建议检查一下是否有数据倾斜 >> > > >> > > >> > > 在 2021-08-26 10:22:54，"yidan zhao" 写道： >> > > >问题期间的确ckpt时间较长。 >> > > >但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 >> > > > >> > > >Caizhi Weng 于2021年8月26日周四 上午10:20写道： >> > > > >> > > >> Hi！ >> > > >> >> > > >> 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ >> > > >> >> > > >> yidan zhao 于2021年8月26日周四 上午10:09写道： >> > > >> >> > > >> > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 >> > > >> > >> > > >> > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh >> > > >> > >> > > >> >> > > >> > >> >
Re: Re: Flink任务假死；无限100%反压；但下游节点无压力。
目前来看，我运行6小时，window总计才收到200MB数据，这个数据量级相比我很多小到没有一样。所以很难想象反压的原因是啥究竟。 目前来看反压节点的outPoolUsage是1，看起来合理，因为处于100%反压。 下游节点的inPoolUsage却是0，这个也很奇怪，同时下游buzz和backpress都是0%. Shengkai Fang 于2021年8月26日周四 下午12:33写道： > - 得看一下具体的卡死的节点的栈，分析下具体的工作任务才知道。 > - 日志中有包含错误的信息吗？ > > Best, > Shengkai > > yidan zhao 于2021年8月26日周四 下午12:03写道： > > > 可能存在机器压力倾斜，但是我是不太清楚这种现象的原因，直接停滞了任务？ > > > > 东东 于2021年8月26日周四 上午11:06写道： > > > > > 建议检查一下是否有数据倾斜 > > > > > > > > > 在 2021-08-26 10:22:54，"yidan zhao" 写道： > > > >问题期间的确ckpt时间较长。 > > > >但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 > > > > > > > >Caizhi Weng 于2021年8月26日周四 上午10:20写道： > > > > > > > >> Hi！ > > > >> > > > >> 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ > > > >> > > > >> yidan zhao 于2021年8月26日周四 上午10:09写道： > > > >> > > > >> > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 > > > >> > > > > >> > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh > > > >> > > > > >> > > > > > >
Re: Re: Flink任务假死；无限100%反压；但下游节点无压力。
- 得看一下具体的卡死的节点的栈，分析下具体的工作任务才知道。 - 日志中有包含错误的信息吗？ Best, Shengkai yidan zhao 于2021年8月26日周四 下午12:03写道： > 可能存在机器压力倾斜，但是我是不太清楚这种现象的原因，直接停滞了任务？ > > 东东 于2021年8月26日周四 上午11:06写道： > > > 建议检查一下是否有数据倾斜 > > > > > > 在 2021-08-26 10:22:54，"yidan zhao" 写道： > > >问题期间的确ckpt时间较长。 > > >但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 > > > > > >Caizhi Weng 于2021年8月26日周四 上午10:20写道： > > > > > >> Hi！ > > >> > > >> 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ > > >> > > >> yidan zhao 于2021年8月26日周四 上午10:09写道： > > >> > > >> > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 > > >> > > > >> > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh > > >> > > > >> > > >
Re: Re: Flink任务假死；无限100%反压；但下游节点无压力。
可能存在机器压力倾斜，但是我是不太清楚这种现象的原因，直接停滞了任务？ 东东 于2021年8月26日周四 上午11:06写道： > 建议检查一下是否有数据倾斜 > > > 在 2021-08-26 10:22:54，"yidan zhao" 写道： > >问题期间的确ckpt时间较长。 > >但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 > > > >Caizhi Weng 于2021年8月26日周四 上午10:20写道： > > > >> Hi！ > >> > >> 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ > >> > >> yidan zhao 于2021年8月26日周四 上午10:09写道： > >> > >> > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 > >> > > >> > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh > >> > > >> >
Re:Re: Flink任务假死；无限100%反压；但下游节点无压力。
建议检查一下是否有数据倾斜 在 2021-08-26 10:22:54，"yidan zhao" 写道： >问题期间的确ckpt时间较长。 >但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 > >Caizhi Weng 于2021年8月26日周四 上午10:20写道： > >> Hi！ >> >> 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ >> >> yidan zhao 于2021年8月26日周四 上午10:09写道： >> >> > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 >> > >> > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh >> > >>
Re: Flink任务假死；无限100%反压；但下游节点无压力。
问题期间的确ckpt时间较长。 但是，这个任务正常ckpt时间才不到1s，ckpt大小也就21MB，所以也很难说ckpt为啥会超时，我超时设置的2min。 Caizhi Weng 于2021年8月26日周四 上午10:20写道： > Hi！ > > 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ > > yidan zhao 于2021年8月26日周四 上午10:09写道： > > > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 > > > > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh > > >
Re: Flink任务假死；无限100%反压；但下游节点无压力。
Hi！ 从图中情况来看很可能是因为下游 checkpoint 时间过长导致反压上游。是否观察过 checkpoint 的情况？ yidan zhao 于2021年8月26日周四 上午10:09写道： > 如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 > > 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh >
Flink任务假死；无限100%反压；但下游节点无压力。
如题，这个问题以前遇到过，后来发生频率低了，近期又多了几次，下面是具体的话题讨论，email不方便贴图。 语雀：https://www.yuque.com/sixhours-gid0m/ls9vqu/rramvh
Re: 任务假死
Hi yanggang, 看了你的描述，我大概知道问题在哪了。首先，我觉得你的启动配置可以优化下，你的配置 -p 200 -ys 5， 也就是说，你的 Flink 任务默认并发是 200，然后每个 TaskManger 有五个槽。 每个槽的内存是一个 TaskManager 的内存的 1 / 5。 如果默认的 TaskManager 内存是1 G 话，相当于你一个槽里面只有 200 M，这样给 JVM 堆栈真正的内存就会更少。 从你的日志中，也出现了 java.lang.OutOfMemoryError: unable to create newnative thread。因为在 Flink 中，有很多地方需要创建 Thread, 一个 Thread 在 JVM，需要有一定的栈空间，默认 1M ， 现在应该是由于槽的内存太小，导致线程栈没有内存分配。 Flink 任务 Task 容错恢复时，需要将状态从 Running -> Canceling -> Canceled，最底层需要启动一个后台线程去 cancel. 但是现在由于不能够创建线程，所以会有 Task 存存在 hang 住(假死)情况，也就是一直显示 Canceling. 个人建议将参数改一下： -p 64 -ytm 2048，之后在观察一下 Best, LakeShen Weihua Hu 于2020年4月27日周一 下午6:27写道： > 你配置的 jobmanager.execution.failover-strategy 是什么呢？如果是 region 的话，作业不会因为 Task > 失败状态变为异常。 > 可以在WEB ui 进入作业拓扑查看单个 task 的状态 > > > Best > Weihua Hu > > > 2020年4月26日 11:43，yanggang_it_job 写道： > > > > 感谢您的回复，这个问题和您刚才给我的场景有些相似，但还是有些许差异。 > > 刚才试了几种方式，图片好像都无法访问。 > > 下面我详细介绍下异常情况 > > 1、我的任务是从三个kafka读取，然后通过onGroup实现left > join语义，然后定义了一个滑动窗口（600，10），最后通过一个CoGroupFunction进行处理具体的数据 > > 2、异常出现在其中一个CoGruopFunction（Window(TumblingEventTimeWindows(60), > EventTimeTrigger, CoGroupWindowFunction) (15/200)）报OOM，异常栈如下 > > java.lang.OutOfMemoryError: unable to create newnative thread > >at java.lang.Thread.start0(NativeMethod) > >at java.lang.Thread.start(Thread.java:717) > >at > java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) > >at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378) > >at > org.apache.flink.streaming.runtime.tasks.StreamTask$CheckpointingOperation.executeCheckpointing(StreamTask.java:1237) > >at > org.apache.flink.streaming.runtime.tasks.StreamTask.checkpointState(StreamTask.java:872) > >at > org.apache.flink.streaming.runtime.tasks.StreamTask.performCheckpoint(StreamTask.java:777) > >at > org.apache.flink.streaming.runtime.tasks.StreamTask.triggerCheckpointOnBarrier(StreamTask.java:708) > >at org.apache.flink.streaming.runtime.io > .CheckpointBarrierHandler.notifyCheckpoint(CheckpointBarrierHandler.java:88) > >at org.apache.flink.streaming.runtime.io > .CheckpointBarrierTracker.processBarrier(CheckpointBarrierTracker.java:137) > >at org.apache.flink.streaming.runtime.io > .CheckpointedInputGate.pollNext(CheckpointedInputGate.java:155) > >at org.apache.flink.streaming.runtime.io > .StreamTaskNetworkInput.pollNextNullable(StreamTaskNetworkInput.java:102) > >at org.apache.flink.streaming.runtime.io > .StreamTaskNetworkInput.pollNextNullable(StreamTaskNetworkInput.java:47) > >at org.apache.flink.streaming.runtime.io > .StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:135) > >at > org.apache.flink.streaming.runtime.tasks.StreamTask.processInput(StreamTask.java:279) > >at > org.apache.flink.streaming.runtime.tasks.StreamTask.run(StreamTask.java:301) > >at > org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:406) > >at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:705) > >at org.apache.flink.runtime.taskmanager.Task.run(Task.java:530) > >at java.lang.Thread.run(Thread.java:748) > > > > 3、除了这个算子vertice为FAILED，其他vertice都为CANCELED，JobManager状态为RUNNING > > > > > > 正常情况下出现这个错，JM会找一台合适的机器重新把TM启起来或者多次尝试后，任务退出。 > > 但是现在任务的运行状态为RUNNING，虽然为RUNNING但是也不写入数据到下游存储。 > > > > > > > > > > > > > > > > thanks > > > > > > 在 2020-04-26 11:01:04，"Zhefu PENG" 写道： > >> 图好像挂了看不到。是不是和这两个场景描述比较相似 > >> > >> [1] http://apache-flink.147419.n8.nabble.com/flink-kafka-td2386.html > >> [2] http://apache-flink.147419.n8.nabble.com/Flink-Kafka-td2390.html > >> On Sun, Apr 26, 2020 at 10:58 yanggang_it_job > >> wrote: > >> > >>> 1、Flink-UI截图 > >>> 我任务的启动配置是 -p 200 -ys 5，也就是说会有40个TM运行，之前正常运行的时候确实是40个TM，而现在只有1个TM在运行； > >>> 同时通过观察数据的同步时间，任务已经在两天前停止写入数据了，但是查看任务的状态却是RUNNING； > >>> 我的理解是当tm申请失败，那么当前任务就会退出并把状态设置为FINISHED，但是真实情况却是上面描述那样。 > >>> 请问为什么会出现这种情况呢？ > >>> > >>> thanks > >>> > >>> > >>> > >>> > >>> > >>> > >
Re: 任务假死
你配置的 jobmanager.execution.failover-strategy 是什么呢？如果是 region 的话，作业不会因为 Task 失败状态变为异常。 可以在WEB ui 进入作业拓扑查看单个 task 的状态 Best Weihua Hu > 2020年4月26日 11:43，yanggang_it_job 写道： > > 感谢您的回复，这个问题和您刚才给我的场景有些相似，但还是有些许差异。 > 刚才试了几种方式，图片好像都无法访问。 > 下面我详细介绍下异常情况 > 1、我的任务是从三个kafka读取，然后通过onGroup实现left > join语义，然后定义了一个滑动窗口（600，10），最后通过一个CoGroupFunction进行处理具体的数据 > 2、异常出现在其中一个CoGruopFunction（Window(TumblingEventTimeWindows(60), > EventTimeTrigger, CoGroupWindowFunction) (15/200)）报OOM，异常栈如下 > java.lang.OutOfMemoryError: unable to create newnative thread >at java.lang.Thread.start0(NativeMethod) >at java.lang.Thread.start(Thread.java:717) >at > java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) >at > java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378) >at > org.apache.flink.streaming.runtime.tasks.StreamTask$CheckpointingOperation.executeCheckpointing(StreamTask.java:1237) >at > org.apache.flink.streaming.runtime.tasks.StreamTask.checkpointState(StreamTask.java:872) >at > org.apache.flink.streaming.runtime.tasks.StreamTask.performCheckpoint(StreamTask.java:777) >at > org.apache.flink.streaming.runtime.tasks.StreamTask.triggerCheckpointOnBarrier(StreamTask.java:708) >at > org.apache.flink.streaming.runtime.io.CheckpointBarrierHandler.notifyCheckpoint(CheckpointBarrierHandler.java:88) >at > org.apache.flink.streaming.runtime.io.CheckpointBarrierTracker.processBarrier(CheckpointBarrierTracker.java:137) >at > org.apache.flink.streaming.runtime.io.CheckpointedInputGate.pollNext(CheckpointedInputGate.java:155) >at > org.apache.flink.streaming.runtime.io.StreamTaskNetworkInput.pollNextNullable(StreamTaskNetworkInput.java:102) >at > org.apache.flink.streaming.runtime.io.StreamTaskNetworkInput.pollNextNullable(StreamTaskNetworkInput.java:47) >at > org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:135) >at > org.apache.flink.streaming.runtime.tasks.StreamTask.processInput(StreamTask.java:279) >at > org.apache.flink.streaming.runtime.tasks.StreamTask.run(StreamTask.java:301) >at > org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:406) >at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:705) >at org.apache.flink.runtime.taskmanager.Task.run(Task.java:530) >at java.lang.Thread.run(Thread.java:748) > > 3、除了这个算子vertice为FAILED，其他vertice都为CANCELED，JobManager状态为RUNNING > > > 正常情况下出现这个错，JM会找一台合适的机器重新把TM启起来或者多次尝试后，任务退出。 > 但是现在任务的运行状态为RUNNING，虽然为RUNNING但是也不写入数据到下游存储。 > > > > > > > > thanks > > > 在 2020-04-26 11:01:04，"Zhefu PENG" 写道： >> 图好像挂了看不到。是不是和这两个场景描述比较相似 >> >> [1] http://apache-flink.147419.n8.nabble.com/flink-kafka-td2386.html >> [2] http://apache-flink.147419.n8.nabble.com/Flink-Kafka-td2390.html >> On Sun, Apr 26, 2020 at 10:58 yanggang_it_job >> wrote: >> >>> 1、Flink-UI截图 >>> 我任务的启动配置是 -p 200 -ys 5，也就是说会有40个TM运行，之前正常运行的时候确实是40个TM，而现在只有1个TM在运行； >>> 同时通过观察数据的同步时间，任务已经在两天前停止写入数据了，但是查看任务的状态却是RUNNING； >>> 我的理解是当tm申请失败，那么当前任务就会退出并把状态设置为FINISHED，但是真实情况却是上面描述那样。 >>> 请问为什么会出现这种情况呢？ >>> >>> thanks >>> >>> >>> >>> >>> >>>
Re:Re: 任务假死
感谢您的回复，这个问题和您刚才给我的场景有些相似，但还是有些许差异。 刚才试了几种方式，图片好像都无法访问。 下面我详细介绍下异常情况 1、我的任务是从三个kafka读取，然后通过onGroup实现left join语义，然后定义了一个滑动窗口（600，10），最后通过一个CoGroupFunction进行处理具体的数据 2、异常出现在其中一个CoGruopFunction（Window(TumblingEventTimeWindows(60), EventTimeTrigger, CoGroupWindowFunction) (15/200)）报OOM，异常栈如下 java.lang.OutOfMemoryError: unable to create newnative thread at java.lang.Thread.start0(NativeMethod) at java.lang.Thread.start(Thread.java:717) at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:957) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1378) at org.apache.flink.streaming.runtime.tasks.StreamTask$CheckpointingOperation.executeCheckpointing(StreamTask.java:1237) at org.apache.flink.streaming.runtime.tasks.StreamTask.checkpointState(StreamTask.java:872) at org.apache.flink.streaming.runtime.tasks.StreamTask.performCheckpoint(StreamTask.java:777) at org.apache.flink.streaming.runtime.tasks.StreamTask.triggerCheckpointOnBarrier(StreamTask.java:708) at org.apache.flink.streaming.runtime.io.CheckpointBarrierHandler.notifyCheckpoint(CheckpointBarrierHandler.java:88) at org.apache.flink.streaming.runtime.io.CheckpointBarrierTracker.processBarrier(CheckpointBarrierTracker.java:137) at org.apache.flink.streaming.runtime.io.CheckpointedInputGate.pollNext(CheckpointedInputGate.java:155) at org.apache.flink.streaming.runtime.io.StreamTaskNetworkInput.pollNextNullable(StreamTaskNetworkInput.java:102) at org.apache.flink.streaming.runtime.io.StreamTaskNetworkInput.pollNextNullable(StreamTaskNetworkInput.java:47) at org.apache.flink.streaming.runtime.io.StreamOneInputProcessor.processInput(StreamOneInputProcessor.java:135) at org.apache.flink.streaming.runtime.tasks.StreamTask.processInput(StreamTask.java:279) at org.apache.flink.streaming.runtime.tasks.StreamTask.run(StreamTask.java:301) at org.apache.flink.streaming.runtime.tasks.StreamTask.invoke(StreamTask.java:406) at org.apache.flink.runtime.taskmanager.Task.doRun(Task.java:705) at org.apache.flink.runtime.taskmanager.Task.run(Task.java:530) at java.lang.Thread.run(Thread.java:748) 3、除了这个算子vertice为FAILED，其他vertice都为CANCELED，JobManager状态为RUNNING 正常情况下出现这个错，JM会找一台合适的机器重新把TM启起来或者多次尝试后，任务退出。 但是现在任务的运行状态为RUNNING，虽然为RUNNING但是也不写入数据到下游存储。 thanks 在 2020-04-26 11:01:04，"Zhefu PENG" 写道： >图好像挂了看不到。是不是和这两个场景描述比较相似 > >[1] http://apache-flink.147419.n8.nabble.com/flink-kafka-td2386.html >[2] http://apache-flink.147419.n8.nabble.com/Flink-Kafka-td2390.html >On Sun, Apr 26, 2020 at 10:58 yanggang_it_job >wrote: > >> 1、Flink-UI截图 >> 我任务的启动配置是 -p 200 -ys 5，也就是说会有40个TM运行，之前正常运行的时候确实是40个TM，而现在只有1个TM在运行； >> 同时通过观察数据的同步时间，任务已经在两天前停止写入数据了，但是查看任务的状态却是RUNNING； >> 我的理解是当tm申请失败，那么当前任务就会退出并把状态设置为FINISHED，但是真实情况却是上面描述那样。 >> 请问为什么会出现这种情况呢？ >> >> thanks >> >> >> >> >> >>
回复：任务假死
同问，我这里也会经常出现这种情况，我现在是写的代码自动kill，这是bug吗？ | | apache22 邮箱：apach...@163.com | Signature is customized by Netease Mail Master 在2020年04月26日 11:01，Zhefu PENG 写道： 图好像挂了看不到。是不是和这两个场景描述比较相似 [1] http://apache-flink.147419.n8.nabble.com/flink-kafka-td2386.html [2] http://apache-flink.147419.n8.nabble.com/Flink-Kafka-td2390.html On Sun, Apr 26, 2020 at 10:58 yanggang_it_job wrote: > 1、Flink-UI截图 > 我任务的启动配置是 -p 200 -ys 5，也就是说会有40个TM运行，之前正常运行的时候确实是40个TM，而现在只有1个TM在运行； > 同时通过观察数据的同步时间，任务已经在两天前停止写入数据了，但是查看任务的状态却是RUNNING； > 我的理解是当tm申请失败，那么当前任务就会退出并把状态设置为FINISHED，但是真实情况却是上面描述那样。 > 请问为什么会出现这种情况呢？ > > thanks > > > > > >
Re: 任务假死
图好像挂了看不到。是不是和这两个场景描述比较相似 [1] http://apache-flink.147419.n8.nabble.com/flink-kafka-td2386.html [2] http://apache-flink.147419.n8.nabble.com/Flink-Kafka-td2390.html On Sun, Apr 26, 2020 at 10:58 yanggang_it_job wrote: > 1、Flink-UI截图 > 我任务的启动配置是 -p 200 -ys 5，也就是说会有40个TM运行，之前正常运行的时候确实是40个TM，而现在只有1个TM在运行； > 同时通过观察数据的同步时间，任务已经在两天前停止写入数据了，但是查看任务的状态却是RUNNING； > 我的理解是当tm申请失败，那么当前任务就会退出并把状态设置为FINISHED，但是真实情况却是上面描述那样。 > 请问为什么会出现这种情况呢？ > > thanks > > > > > >
任务假死
1、Flink-UI截图 我任务的启动配置是 -p 200 -ys 5，也就是说会有40个TM运行，之前正常运行的时候确实是40个TM，而现在只有1个TM在运行； 同时通过观察数据的同步时间，任务已经在两天前停止写入数据了，但是查看任务的状态却是RUNNING； 我的理解是当tm申请失败，那么当前任务就会退出并把状态设置为FINISHED，但是真实情况却是上面描述那样。 请问为什么会出现这种情况呢？ thanks
