spark 使用中会遇到的一些问题及解决思路
7 内存溢出问题
但是，上述情况是在yarn-cluster模式下出现，yarn-client模式运行时倒是正常的，原来在$SPARK_HOME/bin/spark-class文件中已经设置了持久代大小：
排查其前后的日志，发现大都是序列化的东西：
而在 spark-default.conf中，事先设置了序列化方式为Kryo：
在Spark中使用hql方法执行hive语句时，由于其在查询过程中调用的是Hive的获取元数据信息、SQL解析，并且使用Cglib等进行序列化反序列化，中间可能产生较多的class文件，导致JVM中的持久代使用较多，如果配置不当，可能引起类似于如下的OOM问题：
原因是实际使用时，如果用的是JDK1.6版本，
Server模式的持久代默认大小是64M，Client模式的持久代默认大小是32M，而Driver端进行SQL处理时，其持久代的使用可能会达到90M，导致OOM溢出，任务失败。
解决方法就是在Spark的conf目录中的
spark-defaults.conf里，增加对Driver的JVM配置，因为Driver才负责SQL的解析和元数据获取。配置如下：
但是，上述情况是在yarn-cluster模式下出现，yarn-client模式运行时倒是正常的，原来在$SPARK_HOME/bin/spark-class文件中已经设置了持久代大小：
当以yarn-client模式运行时，driver就运行在客户端的spark-submit进程中，其JVM参数是取的spark-class文件中的设置，所谓未出现持久代溢出现象。
总结一下Spark中各个角色的JVM参数设置：
(1)Driver的JVM参数：
-Xmx，-Xms，如果是yarn-client模式，则默认读取 spark-env文件中的SPARK_DRIVER_MEMORY值，-Xmx，-Xms值一样大小；如果是yarn-cluster模式，则读取的是spark-default.conf文件中的spark.driver.extraJavaOptions对应的JVM参数值。
PermSize，如果是yarn-client模式，则是默认读取spark-class文件中的JAVA_OPTS="-XX:MaxPermSize=256m $OUR_JAVA_OPTS"值；如果是yarn-cluster模式，读取的是spark-default.conf文件中的spark.driver.extraJavaOptions对应的JVM参数值。
GC方式，如果是yarn-client模式，默认读取的是spark-class文件中的JAVA_OPTS；如果是yarn-cluster模式，则读取的是spark-default.conf文件中的spark.driver.extraJavaOptions对应的参数值。
以上值最后均可被spark-submit工具中的--driver-java-options参数覆盖。
-Xmx，-Xms，如果是yarn-client模式，则默认读取 spark-env文件中的SPARK_DRIVER_MEMORY值，-Xmx，-Xms值一样大小；如果是yarn-cluster模式，则读取的是spark-default.conf文件中的spark.driver.extraJavaOptions对应的JVM参数值。
PermSize，如果是yarn-client模式，则是默认读取spark-class文件中的JAVA_OPTS="-XX:MaxPermSize=256m $OUR_JAVA_OPTS"值；如果是yarn-cluster模式，读取的是spark-default.conf文件中的spark.driver.extraJavaOptions对应的JVM参数值。
GC方式，如果是yarn-client模式，默认读取的是spark-class文件中的JAVA_OPTS；如果是yarn-cluster模式，则读取的是spark-default.conf文件中的spark.driver.extraJavaOptions对应的参数值。
以上值最后均可被spark-submit工具中的--driver-java-options参数覆盖。
(2)Executor的JVM参数：
-Xmx，-Xms，如果是yarn-client模式，则默认读取spark-env文件中的SPARK_EXECUTOR_MEMORY值，-Xmx，-Xms值一样大小；如果是yarn-cluster模式，则读取的是spark-default.conf文件中的spark.executor.extraJavaOptions对应的JVM参数值。
PermSize，两种模式都是读取的是 spark-default.conf文件中的spark.executor.extraJavaOptions对应的JVM参数值。
GC方式，两种模式都是读取的是spark-default.conf文件中的spark.executor.extraJavaOptions对应的JVM参数值。
-Xmx，-Xms，如果是yarn-client模式，则默认读取spark-env文件中的SPARK_EXECUTOR_MEMORY值，-Xmx，-Xms值一样大小；如果是yarn-cluster模式，则读取的是spark-default.conf文件中的spark.executor.extraJavaOptions对应的JVM参数值。
PermSize，两种模式都是读取的是 spark-default.conf文件中的spark.executor.extraJavaOptions对应的JVM参数值。
GC方式，两种模式都是读取的是spark-default.conf文件中的spark.executor.extraJavaOptions对应的JVM参数值。
(3)Executor数目及所占CPU个数
如果是yarn-client模式，Executor数目由spark-env中的SPARK_EXECUTOR_INSTANCES指定，每个实例的数目由SPARK_EXECUTOR_CORES指定； 如果是yarn-cluster模式，Executor的数目由spark-submit工具的--num-executors参数指定，默认是2个实例，而每个Executor使用的CPU数目由--executor-cores指定，默认为1核。
每个Executor运行时的信息可以通过yarn logs命令查看到，类似于如下：
如果是yarn-client模式，Executor数目由spark-env中的SPARK_EXECUTOR_INSTANCES指定，每个实例的数目由SPARK_EXECUTOR_CORES指定； 如果是yarn-cluster模式，Executor的数目由spark-submit工具的--num-executors参数指定，默认是2个实例，而每个Executor使用的CPU数目由--executor-cores指定，默认为1核。
每个Executor运行时的信息可以通过yarn logs命令查看到，类似于如下：
其中，akka.tcp://spark@sparktest1:41606/user/CoarseGrainedScheduler表示当前的Executor进程所在节点，后面的1表示Executor编号，sparktest2表示ApplicationMaster的host，接着的3表示当前Executor所占用的CPU数目。
8 序列化异常
在Spark上执行hive语句的时候，出现类似于如下的异常：
排查其前后的日志，发现大都是序列化的东西：
而在 spark-default.conf中，事先设置了序列化方式为Kryo：
根据异常信息，可见是HashSet转为BitSet类型转换失败，Kryo把松散的HashSet转换为了紧凑的BitSet，把序列化方式注释掉之后，任务可以正常执行。难道Spark的Kryo序列化做的还不到位？
此问题需要进一步跟踪。
9 Executor僵死问题
运行一个Spark任务，发现其运行速度远远慢于执行同样SQL语句的Hive的执行，甚至出现了OOM的错误，最后卡住达几小时！并且Executor进程在疯狂GC。
截取其一Task的OOM异常信息：
可以看到这是在序列化过程中发生的OOM。根据节点信息，找到对应的Executor进程，观察其Jstack信息：
有大量的
BLOCKED线程，继续观察GC信息，发现大量的
FULL GC。
分析，在插入Hive表的时候，实际上需要写HDFS，在此过程的HashJoin时，伴随着大量的Shuffle写操作，JVM的新生代不断GC，Eden Space写满了就往Survivor Space写，同时超过一定大小的数据会直接写到老生代，当新生代写满了之后，也会把老的数据搞到老生代，如果老生代空间不足了，就触发FULL GC，还是空间不够，那就OOM错误了，此时线程被Blocked，导致整个Executor处理数据的进程被卡住。
当处理大数据的时候，如果
JVM配置不当就容易引起上述问题。解决的方法就是增大Executor的使用内存，合理配置新生代和老生代的大小，可以将老生代的空间适当的调大点
引用： http://www.cnblogs.com/Scott007/p/3889959.html