转自 大蕉
还有这个GAN
http://www.jianshu.com/p/5842ca632816?utm_campaign=haruki&utm_content=note&utm_medium=reader_share&utm_source=weixin
还有这个
http://www.jianshu.com/p/52a3ceedadc5
小伙伴在写Spark任务的过程中感觉非常巨痛苦,总是有奇奇怪怪的问题,写好的程序在开发环境跑得好好的,一上到生产直接被干懵逼了。今天呢,我就跟大伙好好聊聊 Spark 在启动或者运行时的报错或者太慢,并分析其原因及解决方案。自己亲手挖的坑,抹着泪也要趟过去。现在我就跟你们细细说说我过去一年实际经验亲脚趟的坑。
00000:Spark on yarn 启动的时候一直在 waiting。
第一种可能,队列资源不足,所有的资源都在被其他同学占用ing。
解决方案:把那个同学打晕,然后kill application。
第二种可能,设置的 Driver 或者 executor 的 cpu 或者 memory 资源太多。
解决方案:看看队列资源有多少,拿小本本计算一下究竟能申请多少,然后给自己一巴掌。如果集群资源太烂,单台机器只有16G,那你就别动不动就申请一个 driver 或者 executor 一下就来个32G了。
第三种可能,程序报错了,一直在重试。
解决方案:滚回去debug去。
特别提醒:Spark 默认是有10%的内存的 overhead 的,所以会比你申请的多10%。
00001:Driver 抛 OutOfMemory Exception
很明显嘛,就是driver的内存不足了,尝试看一下哪个地方占用内存太多了,特别提醒一下,stage的切分,task的分配都是在Driver 分配的,数量太多的话会爆炸。以及collect(),count()等这些操作都是需要把所有信息搜集到driver端的。
解决方案:打自己一巴掌,然后看dump日志或者看看自己的代码,是不是哪里搞错了。如果一切都很合理,那就提高一下内存吧。
00010:executor 抛 OutOfMemory Exception
内存不足。哇,那这个可能性就多了。
是不是数据量太大 partition 数太少?太少了就多加点 partition 。
是不是产生数据倾斜了?解决它。
是不是某个操作,比如flatmap,导致单个executor产生大量数据了?
是不是请求的内存实在太少了?
00011:executor 抛 is running beyond physical memory limit
哇,你的集群资源超分配了,物理资源被其他团队用了,GG思密达,快拿起40米长木棍。把那个人抓出来。
00100:driver 或者 executor 抛 OutOfMemoryError: GC overhead limit exceeded
出现内存泄漏或者真的集群资源不够,一直在full GC超过次数限制了,仔细检查一下哪些东西占用内存太多,是不是RDD持久化占用太多资源了,还是数据有倾斜,还是真的partition太少导致每个partition数据太多。
00101:运行 GraphX 的时候 driver 抛 OutOfMemory Exception
运行 GraphX 的时候因为会迭代计算,所以会产生非常非常多 stage,这时候 driver 可能没有足够多的内存可以放下这些 stage 和 task 的状态,很容易就出现 OOM。这时候能做的事情就四个,第一增加 driver 内存,第二降低 partition 的数量,第三减少 Pregel 的迭代次数减少stage的数量,第四优化图的切分策略。
00110:大对象网络传输慢。
放弃默认的 Java Serialization,改用 Kryo Serialization。
小对象用广播的模式,避免全局 join。
GraphX 来说改善图切分策略,减少网络交互。
GraphX 尽量单台机器配置高点,可以尽量让更多的 partition 在同一台机器。
00111:SparkStreaming 消息堆积。
调整窗口时间,着重分析消息消费过程的瓶颈并调整相应的资源,尽量降低单笔计算时间。然后根据收集的信息再根据吞吐量来决定窗口时间。
01000:进行 Shuffle 的时候报 Spark Shuffle FetchFailedException。
数据在 Shuffle 的时候中间数据量过大或者数据产生了倾斜,导致部分目标机器崩溃。通过分析崩溃的时候的任务,改善数据 Shuffle 时的数据分布情况。