【Flink】 Flink 应用资源分配问题排查思路

x33g5p2x  于2021-12-05 转载在 Flink  
字(1.9k)|赞(0)|评价(0)|浏览(496)

1.概述

转载: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-factoryarn.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。

  1. 确认应用确实有 YARN 未能满足的资源请求:从应用列表页点击问题应用 ID 进入应用页面,再点击下方列表的应用实例 ID 进入应用实例页面,看 Total Outstanding Resource Requests 列表中是否有 Pending 资源,如果没有,说明 YARN 已分配完毕,退出该检查流程,转去检查 AM;如果有,说明调度器未能完成分配,跳转到步骤4;
  2. 调度器分配问题排查,YARN-9050 支持在 WebUI 上或通过 REST API 自动诊断应用问题,将在 Hadoop3.3.0 发布,之前的版本仍需进行人工排查:
  • 检查集群或 queue 资源,scheduler 页面树状图叶子队列展开查看资源信息:Effective Max Resource、Used Resources:
    (1)检查集群资源或所在队列资源或其父队列资源是否已用完
    (2)检查叶子队列某维度资源是否接近或达到上限;
  • 检查是否存在资源碎片:
    (1)检查集群 Used 资源和 Reserved 资源之和占总资源的比例,当集群资源接近用满时(例如 90% 以上),可能存在资源碎片的情况,应用的分配速度就会受影响变慢,因为大部分机器都没有资源了,机器可用资源不足会被 reserve,reserved 资源达到一定规模后可能导致大部分机器资源被锁定,后续分配可能就会变慢
    (2)检查 NM 可用资源分布情况,即使集群资源使用率不高,也有可能是因为各维度资源分布不同造成,例如 1/2 节点上的内存资源接近用满 CPU 资源剩余较多,1/2 节点上的 CPU 资源接近用满内存资源剩余较多,申请资源中某一维度资源值配置过大也可能造成无法申请到资源;
  • 检查是否有高优先级的问题应用频繁申请并立即释放资源的问题,这种情况会造成调度器忙于满足这一个应用的资源请求而无暇顾及其他应用;
  • 检查是否存在 Container 启动失败或刚启动就自动退出的情况,可以查看 Container 日志(包括 localize 日志、launch 日志等)、YARN NM 日志或 YARN RM 日志进行排查。

相关文章