目前是在所有taskmanager容器都成功启动之后，才出现的timeout，所以不可能是调度层面的问题。
目前我们在网络层面使用的是生产环境的网络，该环境被用于跑大量的生产流量，也没有其他容器反馈过类似问题。
我目前还是比较怀疑flink本身的某个配置导致了这个现象，请问flink是否有相关的metrics或日志可以参考？
On 2021/8/4, 11:50 AM, "东东" wrote:
应该可以从两个层面查一下：
1、调度层面。native
应该可以从两个层面查一下：
1、调度层面。native
application是先启动JM容器，然后由JM容器与K8s交互拉起TM的，可以看一下K8s日志，看看整个流程是否有瓶颈点，比如镜像的拉取，TM容器的启动之类。
2、网络层面。如果调度没有问题，各容器启动的过程和速度都很正常，那就要看网络层面是否存在瓶颈，必要的时候可以tcpdump一下。
在 2021-08-03 14:02:53，"Chenyu Zheng" 写道：
开发者您好，
我正在尝试在Kubernetes上部署Flink 1.12.2，使用的是native
是因为上游事件源速率比较大，需要提高并行度来匹配速率
谢谢！
On 2021/8/3, 2:41 PM, "Ye Chen" wrote:
你好，
请问一下为什么要设置128并行度，这个数值有点太大了，出于什么考虑设置的
在 2021-08-03 14:02:53，"Chenyu Zheng" 写道：
开发者您好，
我正在尝试在Kubernetes上部署Flink 1.12.2，使用的是native
你好，
请问一下为什么要设置128并行度，这个数值有点太大了，出于什么考虑设置的
在 2021-08-03 14:02:53，"Chenyu Zheng" 写道：
开发者您好，
我正在尝试在Kubernetes上部署Flink 1.12.2，使用的是native
application部署模式。但是在测试中发现，当将作业并行度调大之后，各种timeout时有发生。根据监控看，JM和TM容器的cpu和内存都没有使用到k8s给分配的量。
在尝试调大akka.ask.timeout至1分钟，和heartbeat.timeout至2分钟之后，各种超时现象得以缓解。
Taskmanager timeout:
java.util.concurrent.CompletionException:
org.apache.flink.client.deployment.application.ApplicationExecutionException:
Could not execute application.
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292)
~[?:1.8.0_282]
更正，这个是akka timeout exception
java.util.concurrent.CompletionException:
org.apache.flink.client.deployment.application.ApplicationExecutionException:
Could not execute application.
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292)
AKKA timeout
java.util.concurrent.CompletionException:
org.apache.flink.client.deployment.application.ApplicationExecutionException:
Could not execute application.
at
java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:292)
~[?:1.8.0_282]
