小伙伴在写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 时的数据分布情况。
嘛，加油。
你不点个赞吗
共同学习，写下你的评论
评论加载中...
作者其他优质文章
