【spark2】“spark2 on yarn client提交模式下报错：XXXX line xx: xxxx 已杀死 ”问题剖析

前言

报错内容：

ai-bigdata-20200806.sh： 行 24： 10259 已杀死 spark2-submit --driver-memory 14G --executor-memory 16G --driver-cores 2 --executors-cores 3 --num-executors 64 --conf spark.shuffle.consolidateFiles=true --conf.scheduler.listenerbus.eventqueue.size=500000 --conf spark.ui.retainedTasks=310000 --conf spark.dynamicAllocation.maxExecutors=100 --conf spark.driver.maxResultSize=4G --master yarn --deploy-mode client --name jack_roy --files ${file_path} spark_cluster.py "$@"

关于这个报错，我也查证了一些资料，结果是相关叙述并不多，有价值的叙述只有两条。

描述

观点内容

• 观点一：与excutor-memory内存有关，认为加大该配置能够解决问题：
  
• 观点二：认为与宿主机内存有关，加大宿主机内存就能解决该问题：
  

问题发现

虽然第一个观点给出了详细的排错与解决过程，但是本质上来说，我反而认为第二个观点更接近真相，它将我的目光牵引到了宿主机内存问题上。
但是，需要说明的是，我说使用的宿主机是采用超线程40核+256GB内存的刀片机，所以观点二所说的加大宿主机内存在我这里并不可行，但它仍旧给了我极大启发，使我的思维没有被限定在spark或者yarn的层面上。

内存原因

使用spark作为大数据处理框架，我们免不了对内存中的各类数据进行炒作，这其中由于数据倾斜带来的超时、oom问题虽然让我们头疼，但也见怪不怪了。
本次报错的作业是在处理TB级别的数据时除了问题，一开始的猜疑方向也是在spark和yarn的机制上面，但奇怪的是，这个作业时不时的也能跑过去，但多数情况下是半道崩殂，为此我十分费解，多方求证，却意外的发现，将提交模式修改为cluster模式后，作业100%能够跑过去。
这样的发现更令我觉得费解，究竟是什么导致client模式下的意外夭折？
简单思考后，我突然惊觉这一切或许与spark、yarn没什么关系，而是Centos自身的机制杀死了这个作业，或者说是线程。
朝着这个方向思考后，事实上证明是对的，我们在submit一个作业后，本地会保留一个线程来监听作业的运行。如果是client模式，driver跑在本地，这极大消耗了本地资源（尽快driver吃不了多少内存，但是我们的宿主机上可能运行着一些其他的服务，多方服务消耗下，宿主机就会显得很busy）。

OOM机制

这里的OOM机制指的不是yarn的OOM，而是Linux本身内核的一个机制：OOM killer（Out-Of-Memory killer）。
简单来说，这个机制的存在是为了保护我们的Linux系统在繁忙的时候能够自救，主动释放一部分资源，避免整个系统崩溃掉。这个机制的实现很简单，就是在必要的时候杀掉一些线程，以达到释放资源的目的。
毫无疑问，我们的spark Job是被这个机制杀掉了，杀掉的原因是因为我们在内核的评分score太高了，所以触发机制的时候，优先被杀（有兴趣的可以详细了解下这个机制，还是挺有意思的）。

解决方案

解决方案很简单，就是让OMM killer机制不再杀我们的作业，也就是将我们的score分值降下来，关于这个打分机制，其实也很有意思，感兴趣的一定要去查阅资料看一下，我这里就不赘述，直接说结果。
降低这个分值的办法有好几种，可以从父线程那里将，也可以在线程启动后手动降，我是采用后者。
作业submit之后，寻找我们作业线程的PID：

ps aux | grep [关键字]

找到线程PID之后，进入：

cd /proc/[PID]

然后修改oom_adj的范围为-17，这样就禁用了oom（oom_score永远为0，线程就不会被杀了，为得到效果可以前后分别打印oom_score值对比效果）：

#此时 oom_score 应该为一个非零数，且分数通常较高，像我刚启动没一会儿就达到了49，并随着时间流逝，分值还在增加
cat oom_score
echo -17 >> oom_adj
# 此时 oom_score变为零，并不为所动
cat oom_score

然后就可以高枕无忧矣！

后记

有人说，你这个完全是client模式搞的鬼，cluster模式就不会出现这种问题！
的确是这样，不过我们在开发、测试作业的时候，采用client模式更方面调试，而且这种报错不止会发生在我们大数据调度作业上，任何一个运行在Linux上的线程都有可能因为score分数过高而被kill掉，如果我们明白这其中的机制，就能很从容地解决这方面的问题。