Flink 使用之 Yarn 资源问题排查

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官网的解释如下:

  1. maximum-applications check - if the limit is exceeded, the submission is rejected immediately.
  2. 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.
  3. 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.

中文解释为:

  1. 检查maximum-applications。如果超出,拒绝作业提交。(硬限制)
  2. 检查max-parallel-apps。如果超出,作业进入ACCEPTED状态,等到条件满足时候恢复执行。(软限制)
  3. 检查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

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 194,319评论 5 459
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 81,801评论 2 371
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 141,567评论 0 319
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 52,156评论 1 263
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 61,019评论 4 355
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 46,090评论 1 272
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 36,500评论 3 381
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 35,192评论 0 253
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 39,474评论 1 290
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 34,566评论 2 309
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 36,338评论 1 326
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 32,212评论 3 312
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 37,572评论 3 298
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 28,890评论 0 17
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 30,169评论 1 250
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 41,478评论 2 341
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 40,661评论 2 335

推荐阅读更多精彩内容