Flink 利用之 Yarn 资源问题排查

藏宝库编辑 7 天前 3623 0 来自 中国
Flink 利用先容相干文档目次

Flink 利用先容相干文档目次
媒介

Flink作业提交的时候会碰到任务无法提交,大概是长时间处于ACCEPTED状态。此时需要重点排查Yarn的资源的相干设置。
本篇为各人带来Flink on Yarn 资源问题的排查思路。
典型报错

Flink on Yarn步调提交的时候假如资源不足,JobManager会出现类似如下的错误:
java.util.concurrent.CompletionException: org.apache.flink.runtime.jobmanager.scheduler.NoResourceAvailableException: Slot request bulk is not fulfillable! Could not allocate the requeired slot within slot request timeout根因是Yarn的资源不足,大概是凌驾设置限制。
确定Flink利用的资源

首先需要根据Flink设置文件,大概作业的提交命令,确定Flink的资源设置,以及作业提交到了哪个队列,是否指定了node label大概指定了哪个node label。
利用Yarn session提交的Flink作业,留意查抄的参数有:

  • -s: 每个TaskManager的slot数目。
  • -qu: 提交任务到哪个队列。
  • -nl: 作业利用的Yarn标签资源。
  • -jm: JobManager利用的内存。
  • -tm: TaskManager利用的内存。
Yarn cluster模式:

  • -ys: 每个TaskManager的slot数目。
  • -yqu: 提交任务到哪个队列。
  • -ynl: 作业利用的Yarn标签资源。
  • -yjm: JobManager利用的内存。
  • -ytm: TaskManager利用的内存。
另外提交作业时还有:

  • -p: 指定提交作业时的默认并行度。假如作业内算子没有明白指定并行度,则利用该值。覆盖parallelism.default设置值。
flink-conf.yaml设置文件:

  • taskmanager.numberOfTaskSlots: TaskManager slot数目。
  • parallelism.default: 默认的并行度。决定会启动多少个TaskManager。
  • jobmanager.memory.process.size: JobManager总内存巨细。包含堆内,堆外以及JVM metaspace等JVM本身占用的内存巨细。
  • taskmanager.memory.process.size: TaskManager总内存巨细。
Yarn资源相干设置

本节列出了需要重点查抄Yarn的设置。
内存相干:

  • yarn.nodemanager.resource.memory-mb: 每个nodemanager最多可用于分配给container的内存数目。整个Yarn集群的可用内存数目为yarn.nodemanager.resource.memory-mb * nodemanager节点数。
  • yarn.scheduler.minimum-allocation-mb: RM为每个container分配的最小内存数。container占用内存巨细的下限。
  • yarn.scheduler.maximum-allocation-mb: RM为每个container分配的最大内存数。container占用内存巨细的上限。
  • yarn.nodemanager.vmem-pmem-ratio: Container最多利用的假造内存容量和物理内存的比值。默认为2.1。
  • yarn.nodemanager.vmem-check-enabled: 是否开启假造内存查抄,逼迫限制假造内存的利用量。默认为true。
CPU相干:

  • yarn.nodemanager.resource.percentage-physical-cpu-limit: CPU资源可供container利用的百分比。仅在启用CGroup(yarn_cgroups_enabled)的时候才会见效。
  • yarn.nodemanager.resource.cpu-vcores: 每个nodemanager最多可用于分配给container的CPU vcore数目。整个Yarn集群的可用CPU vcore数目为yarn.nodemanager.resource.cpu-vcores * nodemanager节点数。
  • yarn.scheduler.minimum-allocation-vcores: RM为每个container分配的最小CPU vcore数。container占用vcore数目的下限。
  • yarn.scheduler.maximum-allocation-vcores:RM为每个container分配的最大CPU vcore数。container占用vcore数目的上限。
容量调理资源设置:

  • yarn.scheduler.capacity.<queue-path>.capacity: 队列的最小资源数。发生强占的时候也需要保障队列的最小资源。
  • yarn.scheduler.capacity.<queue-path>.maximum-capacity: 队列的最大资源数。在其他队列资源不告急的情况下可以利用凌驾yarn.scheduler.capacity.<queue-path>.capacity的资源。
  • yarn.scheduler.capacity.<queue-path>.minimum-user-limit-percent: 确保用户可得到的最小资源占队列资源的百分比。
  • yarn.scheduler.capacity.<queue-path>.user-limit-factor: 单个用户最多可利用的资源占队列总资源(最小资源)的百分比。
  • yarn.scheduler.capacity.<queue-path>.maximum-allocation-mb: 队列中每个container分配的最大内存数。覆盖yarn.scheduler.maximum-allocation-mb设置。必须小于或即是集群设置。
  • yarn.scheduler.capacity.<queue-path>.maximum-allocation-vcores: 队列中每个container分配的最大CPU vcore数。覆盖yarn.scheduler.maximum-allocation-vcores设置。必须小于或即是集群设置。
  • yarn.scheduler.capacity.<queue-path>.user-settings.<user-name>.weight: 某个用户的资源分配权重值。权庞大的用户分得的资源较多。
容量调理应用限制设置:

  • yarn.scheduler.capacity.maximum-applications / yarn.scheduler.capacity.<queue-path>.maximum-applications: 集群大概队列最多可同时存在的running和pending应用数目。该项是硬限制。凌驾数目限制之后提交的应用会被拒绝。
  • yarn.scheduler.capacity.maximum-am-resource-percent / yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent: 集群或队列中可用于运行Application Master的资源占比。
  • yarn.scheduler.capacity.max-parallel-apps / yarn.scheduler.capacity.<queue-path>.max-parallel-apps: 同样限制最大同时运行应用数但该设置是软限制(集群范围或队列范围)。凌驾数目限制之后提交的应用处于ACCEPTED状态,等候条件符适时运行。
  • yarn.scheduler.capacity.user.max-parallel-apps: (全部用户范围)每个用户最多提交的应用数。软限制。
  • yarn.scheduler.capacity.user.<username>.max-parallel-apps: 某个用户最多提交的应用数。软限制。
资源限制查抄次序:
Hadoop官网的表明如下:

  • maximum-applications check - if the limit is exceeded, the submission is rejected immediately.
  • max-parallel-apps check - the submission is accepted, but the application will not transition to RUNNING state. It stays in ACCEPTED until the queue / user limits are satisfied.
  • maximum-am-resource-percent check - if there are too many Application Masters running, the application stays in ACCEPTED state until there is enough room for it.
中文表明为:

  • 查抄maximum-applications。假如超出,拒绝作业提交。(硬限制)
  • 查抄max-parallel-apps。假如超出,作业进入ACCEPTED状态,比及条件满足时候恢复实行。(软限制)
  • 查抄maximum-am-resource-percent。假如超出,作业进入ACCEPTED状态,比及条件满足时候恢复实行。(软限制)
权限设置:

  • yarn.scheduler.capacity.<queue-path>.state: 队列状态。可以是RUNNING大概STOPPED。STOPPED状态克制提交新应用,但是已经提交的应用可以继续运行直到竣事。
标签调理相干:
Yarn的节点可以被绑定标签。从而可以限制Yarn作业调理的物理节点。当然也能够对作业资源举行限制。需要留意的是没有绑定任何标签的节点自成一类,他们能够被全部队列利用到。
利用yarn node -list -showDetails命令查看Yarn集群节点和节点绑定的label。通过绑定某个label的节点数和前面所述的节点可用内存和vcore设置,可以计算出该label纳管的资源最大值。
队列标签设置:

  • yarn.scheduler.capacity.root.accessible-node-labels: 队列可访问哪些标签资源。无标签的节点资源全部队列都可以访问。
  • yarn.scheduler.capacity.root.default-node-label-expression: 假如提交到该队列的app没有指定标签,则利用default-node-label-expression指定的标签资源。默认情况下该设置项为空,表现app将利用没有标签的节点。此项很紧张,否则当用户提交应用没有指定标签时,即便指定了队列,标签资源仍然不可利用。
假如队列标签设置错误大概是用户提交应用时候利用的标签设置有误,很有大概导致应用无法得到足够的资源,终极无法运行。
Flink资源计算方法

TaskManager数目 = 向上取整(parallelism.default大概实际运行时指定的并行度 / taskmanager.numberOfTaskSlots)
假如各算子并行度差异,parallelism取用并行度最大的算子并行度。
总的Container数目 = 1 + TaskManager数目。
其中1是JobManager(AppMaster角色),它本身占用一个container。
相干Yarn设置:

  • yarn.nodemanager.resource.memory-mb * nodemanager节点数(集群总可用内存数)。
  • yarn.nodemanager.resource.cpu-vcores * nodemanager节点数(集群总可用vcore数)。
  • yarn.scheduler.capacity.<queue-path>.capacity
  • yarn.scheduler.capacity.<queue-path>.maximum-capacity
  • yarn.scheduler.capacity.root.accessible-node-labels
  • yarn.scheduler.capacity.root.default-node-label-expression
需要查抄目的队列的剩余资源是否能够满足作业需要。
每个container的vcore利用量 = taskmanager.numberOfTaskSlots大概-s参数。
相干Yarn设置:

  • yarn.scheduler.minimum-allocation-vcores
  • yarn.scheduler.maximum-allocation-vcores
JobManager container内存利用量 = jobmanager.memory.process.size大概-jm参数。
因为JobManager在Yarn中的角色是AppMaster,因此它的资源利用量受到了yarn.scheduler.capacity.maximum-am-resource-percent设置项的限制。
除此之外还有:

  • yarn.scheduler.minimum-allocation-mb
  • yarn.scheduler.maximum-allocation-mb
  • yarn.scheduler.capacity.<queue-path>.user-limit-factor
TaskManager container内存利用量 = taskmanager.memory.process.size大概-tm参数。
相干Yarn设置:

  • yarn.scheduler.minimum-allocation-mb
  • yarn.scheduler.maximum-allocation-mb
  • yarn.scheduler.capacity.<queue-path>.user-limit-factor
参考链接

https://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/CapacityScheduler.html
https://zhuanlan.zhihu.com/p/335881182
您需要登录后才可以回帖 登录 | 立即注册

Powered by CangBaoKu v1.0 小黑屋藏宝库It社区( 冀ICP备14008649号 )

GMT+8, 2024-10-18 16:45, Processed in 0.166894 second(s), 33 queries.© 2003-2025 cbk Team.

快速回复 返回顶部 返回列表