转载:https://blog.csdn.net/weixin_43970890/article/details/102483720
如果 Flink 应用不能正常启动达到 RUNNING 状态,可以按以下步骤进行排查:
需要先检查应用当前状态,根据上述对启动流程的说明,我们知道:
处于 NEW_SAVING
状态时正在进行应用信息持久化,如果持续处于这个状态我们需要检查 RM 状态存储服务(通常是 ZooKeeper 集群)是否正常;
如果处于 SUBMITTED 状态
,可能是 RM 内部发生一些 hold 读写锁的耗时操作导致事件堆积,需要根据 YARN 集群日志进一步定位;
如果处于 ACCEPTED 状态
,需要先检查 AM 是否正常,跳转到步骤2;
如果已经是 RUNNING 状态
,但是资源没有全部拿到导致 JOB 无法正常运行,跳转到步骤 3;
检查 AM 是否正常
,可以从 YARN 应用展示界面(http:///cluster/app/)或 YARN 应用 REST API(http:///ws/v1/cluster/apps/)查看 diagnostics 信息,根据关键字信息明确问题原因与解决方案:
Queue's AM resource limit exceeded.
原因是达到了队列 AM 可用资源上限,即队列的 AM 已使用资源和 AM 新申请资源之和超出了队列的 AM 资源上限,可以适当调整队列 AM 可用资源百分比的配置项:yarn.scheduler.capacity..maximum-am-resource-percent
。
User's AM resource limit exceeded
. 原因是达到了应用所属用户在该队列的 AM 可用资源上限,即应用所属用户在该队列的 AM 已使用资源和 AM 新申请资源之和超出了应用所属用户在该队列的 AM 资源上限,可以适当提高用户可用 AM 资源比例来解决该问题,相关配置项:yarn.scheduler.capacity..user-limit-factor
与 yarn.scheduler.capacity..minimum-user-limit-percent
。
AM container is launched, waiting for AM container to Register with RM
. 大致原因是 AM 已启动,但内部初始化未完成,可能有 ZK 连接超时等问题,具体原因需排查 AM 日志,根据具体问题来解决。
Application is Activated, waiting for resources to be assigned for AM.
该信息表示应用 AM 检查已经通过,正在等待调度器分配,此时需要进行调度器层面的资源检查,跳转到步骤 4。
确认应用确实有 YARN 未能满足的资源请求
:从应用列表页点击问题应用 ID 进入应用页面,再点击下方列表的应用实例 ID 进入应用实例页面,看 Total Outstanding Resource Requests
列表中是否有 Pending 资源,如果没有,说明 YARN 已分配完毕,退出该检查流程,转去检查 AM;如果有,说明调度器未能完成分配,跳转到步骤4;检查集群或 queue 资源
,scheduler 页面树状图叶子队列展开查看资源信息:Effective Max Resource、Used Resources:检查集群 Used 资源和 Reserved 资源之和占总资源的比
例,当集群资源接近用满时(例如 90% 以上),可能存在资源碎片的情况,应用的分配速度就会受影响变慢,因为大部分机器都没有资源了,机器可用资源不足会被 reserve,reserved 资源达到一定规模后可能导致大部分机器资源被锁定,后续分配可能就会变慢检查 NM 可用资源分布情况
,即使集群资源使用率不高,也有可能是因为各维度资源分布不同造成,例如 1/2 节点上的内存资源接近用满 CPU 资源剩余较多,1/2 节点上的 CPU 资源接近用满内存资源剩余较多,申请资源中某一维度资源值配置过大也可能造成无法申请到资源;版权说明 : 本文为转载文章, 版权归原作者所有 版权申明
原文链接 : https://blog.csdn.net/qq_21383435/article/details/121348818
内容来源于网络,如有侵权,请联系作者删除!