目前是在所有taskmanager容器都成功启动之后，才出现的timeout，所以不可能是调度层面的问题。
目前我们在网络层面使用的是生产环境的网络，该环境被用于跑大量的生产流量，也没有其他容器反馈过类似问题。
我目前还是比较怀疑flink本身的某个配置导致了这个现象，请问flink是否有相关的metrics或日志可以参考？
On 2021/8/4, 11:50 AM, "东东" <dongdongking...@163.com> wrote:
应该可以从两个层面查一下：
1、调度层面。native
application是先启动JM容器，然后由JM容器与K8s交互拉起TM的，可以看一下K8s日志，看看整个流程是否有瓶颈点，比如镜像的拉取，TM容器的启动之类。
2、网络层面。如果调度没有问题，各容器启动的过程和速度都很正常，那就要看网络层面是否存在瓶颈，必要的时候可以tcpdump一下。
在 2021-08-03 14:02:53，"Chenyu Zheng" <chenyu.zh...@hulu.com.INVALID> 写道：
开发者您好，
我正在尝试在Kubernetes上部署Flink 1.12.2，使用的是native
application部署模式。但是在测试中发现，当将作业并行度调大之后，各种timeout时有发生。根据监控看，JM和TM容器的cpu和内存都没有使用到k8s给分配的量。
在尝试调大akka.ask.timeout至1分钟，和heartbeat.timeout至2分钟之后，各种超时现象得以缓解。
我的问题是，当设置较大并行度（比如128）时，akka超时和心跳超时的各种现象都是正常的吗？如果不正常，需要用什么方式去troubleshot问题的根源呢？另外单纯一味调大各个组件的超时时间，会带来什么负面作用呢？
附件中有akka超时的jobmanager日志，TaskManager心跳超时日志稍后会发上来。
谢谢！
