Shuffle Service导致NM OOM问题分析(续)

今天有朋友问之前NodeManager被Shuffle拉挂的问题,借此机会将之前分析的另一文档整理一下分享出来。

现象描述及分析

9月27日10时左右,编号为2611节点执行应用时发生先前描述的NM OOM问题。其中触发该问题的应用的部分信息如下所示:

  • 应用Stage信息如下所示:
Stages for All Jobs

由该图可知,Stage3包含10万+Map任务,Stage4有3000个Reduce任务。
Stage3 中每个Map任务会将处理的数理 Hash成3000份并存入一个文件当中。

  • Stage3阶段, 编号2611节点中分配的Executor信息:


    Aggregated Metrics by Executor

应用其申请100个Executor, 其中4个Executor落在编号为2611节点(为单节点Executor最多的情况),2611中4个Executor共执行3512个Map Task. 即理论上会有3512个shuffle临时文件落在该节点。因为Reduce任务数为3000,所示每个临时文件中包含3000个reduce task的数据(备注:任务数据本无倾斜,调度原因导致倾斜)。

3000个reduce任务会到编号为2611中的3512个文件中取回属于自己的数据,所以共需要打开30003512次文件(FileInputStream数目),然而:
由FailedStages信息可知已执行的Task数约为2200(之后出现错误退出)
则在编号2166节点打开文件次数大约为 3512 * 2200 = 7726400次(考虑索引文件时,该值
2,2611节点约创建1500万FileInputStream).

而通过分析OOM时Dump文件,结果显示Finallizer堆集数量为430万+, 因此理论上Shuffle Service有致使Finallizer堆集至430万+的可能.

应用重试结果

NM挂掉之后, 任务抛出下述异常:

FetchFailed(BlockManagerId(69, ****2611.****.com, 7337)

重新提交后,应用正常执行完成,分析Executor列表,最多两个Executor分配至同一个Node。

问题?

由Shuffle Service原理可知,同一个NM上的所有Executor共用同一个服务, 因此在某个NM上运行的Executor过多时,其对外提供Shuffle服务的负担会变重…特别是同一个应用的多个Executor调度到同个NM时,问题会更加严重, 因为这些Executor的shuffle数据将同一时间被reduce拉取(不同应用会有错峰的可能)。

因此,RM如何为Spark APP分配container会影响Shuffle Server的负载强度,即OOM发生的风险。

==Yarn 调度时是否可以增加如下机制:==

  • ==对同一APP的Container进行调度时,打散到多个NM, 类似于Spark Streaming中Receiver的调度,尽量避免隶属同一APP的Container在同一个NM上堆积==

此举可减轻Shuffle Server负担,可在一定程度上避免OOM发生,再结合之前“Shuffle Service 导致NM OOM问题分析”解决方案,可更好的解决NM 挂掉问题

另外:
同一应用中任务在同一时间会必然竞争相同的资源,若隶属同一个应用的Container过多的落在同一NM上时,在逻辑资源隔离的背景下,理论上会降低任务执行效率。
若将其打散,则应用在某Node上的Container会与其它应用重合,则存在相同资源错峰使用的可能,在一定程度上还会比相同应用Container堆叠时作业执行效率高。

附 网络信息


//由上述Stage信息图可知Stage4  shuffle任务 从09:39开始提交执行,其网络使用情况如下所示:
9:52左右NM日志中开始出现异常信息…  10:05左右NM挂掉…

由该信息可知,shuffle时fetch请求量较非shuffle阶段高很多…

(totsck: socket总数量, tcpsck用于TCP的socket数量)
09:36:01 AM    totsck    tcpsck    udpsck    rawsck   ip-frag    tcp-tw
09:37:01 AM       682       341        10         0         0      5081
09:38:01 AM       711       345        10         0         0      8289
09:39:01 AM       690       353        10         0         0     10512
09:40:01 AM       880       512        10         0         0      8532
09:41:01 AM      1013       660        10         0         0      5957
09:42:01 AM      1879      1589        10         0         0      3357
09:43:01 AM      2717      2434        10         0         0      1251
09:44:01 AM      3445      3150        10         0         0       629
09:45:01 AM      4061      3784        10         0         0       291
09:46:01 AM      4727      4451        10         0         0        81
09:47:01 AM      5639      5362        10         0         0        62
09:48:01 AM      6463      6187        10         0         0        72
09:49:01 AM      7447      7160        10         0         0        94
09:50:01 AM      8453      8176        10         0         0        56
09:51:01 AM      9638      9364        10         0         0       108
09:52:01 AM     10740     10466        10         0         0        56
09:53:01 AM     11808     11533        10         0         0       323
09:54:01 AM     12634     12357        10         0         0       207

09:54:01 AM    totsck    tcpsck    udpsck    rawsck   ip-frag    tcp-tw
09:55:01 AM     13742     13468        10         0         0        71
09:56:01 AM     14859     14584        10         0         0        35
09:57:01 AM     16005     15725        10         0         0        53
09:58:01 AM     17124     16834        10         0         0        71
09:59:01 AM     18213     17925        10         0         0        53
10:00:01 AM     19134     18804        10         0         0        40
10:01:01 AM     19792     19464        10         0         0        38
10:02:01 AM     20394     20102        10         0         0        48
10:03:01 AM     21017     20690        10         0         0        53
10:04:02 AM     21077     20789        10         0         0        26
10:05:01 AM     21897     21584        10         0         0        42
10:06:01 AM       710       393         9         0         0       144
10:07:01 AM       726       404         9         0         0        49

注: 官方Spark 2 版本做了众多与Shuffle Service相关工作(SPARK-21475,20994,20426等),可以拉取相关patch解决该问题。
另外 Yarn社区也有提出System Container的概念,旨在将Shuffle Service等AuxiliaryServices独立于NodeManger之外,可以做为终极解决方案的参考,地址见:https://issues.apache.org/jira/browse/YARN-1593

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