【cfoutofmemory怎么解决】稀疏常见问题摘要

一.火花SQL相关

执行Insert语句时报告错误，堆栈信息为FileSystem closed。经常出现在ThriftServer里面。原因：多线程线程closedFileSystem可能会导致BUG解决方案，因为Hadoop FileSy获取的文件系统是从缓存加载的。如果存在HDFS无法从缓存中加载的解决方案，则可以在Spark运行期间抛出Failed TO BIG DATA 010 CAUSED BY:JAVA . NIO . C原因：这是因为没有配置host运行Sparksql操作orc类型表时，如果修改该系统的主机，则会导致java.lang.indexoutofbs。错误仅在S后修改了解决方法：避免解决方法。修改ORC的默认分区策略如下：Orc的分割分割分割区有三种原则(ETL、BI和HYBIRD)。默认值为HYBIRD(混合模式，根据文件大小和文件数自动选择ETL或BI模式)，BI模式取决于文件数，因为s以前不支持HDFS读取，所以拆分splitS不支持永久函数。使用Saprk-sql和ThriftServer时报告错误：Java . net . socket timeThriftServer解决方案：在获得连接之前添加driver manager . setlogintimeout(100)，以便在操作Snappy压缩表时使用throw:Java . lang . runtime exception :修改配置文件并添加：/task/install/Hadoop/lib/native或-djava.library原因：在生成HaddopRDD的过程中，partitions将参数ma或ma(20)与修改此参数会降低task。ThriftServer登录异常：javax . error validating LDAPuser原因：解决密码错误或LDAP服务异常：解决密码和身份验证问题使用JDBC连接到ThriftServer时，可以执行与show tabls类似的操作，但不能执行与select相关的操作Java . io . io exception : failed to create local dir in/tmp/blockmgr-ADB 70127-0a 28-4256 06。原因：用户长时间不使用ThriftServer，导致系统清理父目录，或者用户对该目录完全没有写权限的解决方法：重新启动ThriftServer和设置目录权限：如果Spark SQL中运行的SQL语句太复杂，则会抛出Java.lang.StackOverflowError异常。这是因为程序运行时的Stack大小比JVM的大小设置解决方法大。在启动Spark-sql时添加-driver-Java-options

• INSERT INTO重复执行出现：Unable to move source hdfs://bigdata05/tmp/hive-hduser1101_hive_2017-09-11_14-50-56_038_2358196375683362770-82/-ext-10000/part-00000 to destination hdfs://bigdata05/user/hive

• 原因：该问题是2.1.0的Bug，在S中已经解决2.1.0。
• 解决方法：2.1.0规避办法INSERT OVERWRITE不带分区重复执行不会出现问题

• 执行大数据量的join等操作时出现：1.Missing an output location for shuffle；2.Failed to connect to bigdata030015; 3.FileNotFoundException……(not such file or directory)。4.Container killed on request. Exit code is 143

• 原因：shuffle分为shuffle write和shuffle read两部分。shuffle write的分区数由上一阶段的RDD分区数控制，shuffle read的分区数则是由Spark提供的一些参数控制。shuffle write可以简单理解为类似于saveAsLocalDiskFile的操作，将计算的中间结果按某种规则临时放到各个executor所在的本地磁盘上。
• shuffle read的时候数据的分区数则是由spark提供的一些参数控制。可以想到的是，如果这个参数值设置的很小，同时shuffle read的量很大，那么将会导致一个task需要处理的数据非常大。结果导致JVM crash（OOM），从而导致取shuffle数据失败，同时executor也丢失了，看到Failed to connect to host的错误，也就是executor lost的意思。有时候即使不会导致JVM crash也会造成长时间的gc
• 解决方法：1. 调优sql。
• 2.SparkSQL和DataFrame的join,group by等操作通过控制分区数，默认为200，根据shuffle的量以及计算的复杂度提高这个值。
• 3.Rdd的join,groupBy,reduceByKey等操作，通过控制shuffle read与reduce处理的分区数，设置大一点。
• 4.通过提高executor的内存设置适当提高executor的memory值。
• 5.判断join过程中是否存在数据倾斜的问题：可以参考链接：

• Sparksql使用过程中Executor端抛出：java.lang.OutOfMemoryError: GC overhead limit exceeded

• 原因：这是由于大部分事件都在GC，导致OOM。
• 解决方法：加大执行器内存，修改GC策略 -XX:+UseG1GC

• hiveserver2和SparkThriftServer使用操作orc表的时候报错A用户无法访问B用户的目录。

• 原因：这是由于orc 在进行Split过冲中会进行用户缓存。ORC在时的BUG，在和S版本后进行了解决
• 解决方法：暂时规避方法比较暴力，1、先使用超级用户进行第一次查询，导致缓存的用户为超级用户。2、设置不进行缓存

• spark-sql在使用过程中小数据量查询很慢，查看sparkUI显示每个Task处理都很快，但是都隔了3秒进行调度导致整体很慢。

• 原因：这是由于数据本地性导致的，默认为3秒
• 解决方法：设置该参数为0即可加快速度，只有在数据量较小的情况下才建议这样设置。

二.Spark core相关

• on yarn启动spark-sql 和spark-submit时出现：java.lang.NoClassDefFoundError: com/sun/jersey/api/client/config/ClientConfig

• 原因：和yarn相关Jersey包冲突
• 解决方法：配置上–conf

• 在使用Spark过程中出现：java.io.IOException: No space left on device

• 原因：一般是由于Spark的tmp目录满了导致
• 解决方法：可以将该目录空间设置大点，支持按逗号分割多个目录：

• 超出最大结果集：is bigger than )

• 原因：默认配置为1G
• 解决方法：调大该参数即可

• 常见OOM：java.lang.OutOfMemoryError: Java heap space

• 原因：1、数据量太大，申请的Executor资源不足以支撑。2.单分区的数据量过大，和分区数过多导致执行task和job存储的信息过多导致Driver OutOfMemoryError
• 解决方法：1、尽量不要使用collect操作。2、查看数据是否有倾斜，增加shuffle的并行度，加大Executor内存

• 由Executor的FullGC引起Executor lost，task失败，各种超时：Futures timed out after【120S】

• 原因：一般是由于Executor处理数据量过大如倾斜导致，从而使Executor full gc导致时间超时，Executor 和 task 的lost
• 解决方法：1、如果通过查看Executor的日志是full GC导致，适当调优SQL，加大Executor内存。2、如果没有fullGC考虑提高：

• jar包版本冲突时：java.lang.ClassNotFoundException: XXX

• 原因：一般可能是用户jar和Spark jar冲突
• 解决方法：1、最好和Spark相关的jar进行适配。2、如果不行可以使用参数：和 设置为true

• 进行shuffle抛出：Shuffle Fetch Failed: OOM

• 原因：Shuffle fetch阶段开启的fetch数据量过大导致
• 解决方法：1、加大Executor内存。2、将参数调小，默认48M

• shuffle报org.a: Direct buffer memory

• 原因：堆外内存不够导致，直接内存
• 解决方法：增大JVM 参数-XX:MaxDirectMemorySize（如： = -XX:MaxDirectMemorySize=xxxm）

• 集群节点异常导致Spark job失败，如磁盘只读。

• 原因：Spark 是一个高性能、容错的分布式计算框架，一旦它知道某个计算所在的机器出现问题会依据之前生成的 lineage 重新在这台机器上调度这个 Task，如果超过失败次数就会导致job失败。
• 解决方法：Spark有黑名单机制，在超出一定次数的失败后不会往该节点或者Executor调度Task。设置相应Black参数：

三.Pyspark相关

• driver python和Executor Python版本不一致问题

• 原因：pyspark要求所有的Executor运行的python版本一致
• 解决方法：指定python的运行路径： /data/Install/Anaconda2Install 或者 env配置上：export PYSPARK_PYTHON=/data/Install/Anaconda2Install；export PYSPARK_DRIVER_PYTHON=/data/Install/Anaconda2Install

• Pyspark使用过程中出现：RDD时出现序列化(obj)报错，EOFError。有时可以，在local也可以。

• 原因：在on yarn时，机器上也有安装相关的Spark。导致包冲突
• 解决方法：删除nodeManager上的Spark安装路径就可以解决

• 运行RDD操作时报Randomness of hash of string should be disabled via PYTHONHASHSEED mean in pyspark

• 原因：这是由于各个Executor的Hash随机值不一样导致。
• 解决方法：只需要指定各Executor的PYTHONHASHSEED环境变量即可如：–conf

四.Streaming相关

• 消费kafka时，第一个job读取了现有所有的消息，导致第一个Job处理过久甚至失败

• 原因：au设置为了earliest 从最早的offset开始进行消费，也没有设置参数
• 解决方法：指定从之前开始消费的数据开始：设置offsetRange。并将参数设置为：au=latest 设置Spark每个分区的速率。

• 尽量使用高性能算子

• 使用reduceByKey/aggregateByKey替代groupByKey
• 使用mapPartitions替代普通map
• 使用foreachPartitions替代foreach
• 使用filter之后进行coalesce操作
• 使用repartitionAndSortWithinPartitions替代repartition与sort类操作

• Streaming如果存在多个Batch延迟时，消费不过来。有时会报出：Hbase相关的异常如：RegionTooBusyException

• 原因：Streaming在进行处理时如果单个Batch读取的数据多，会导致计算延迟甚至导致存储组件性能压力
• 解决方法：1、如果是计算延迟试着调整读取速率如：参数 2、调优存储组件的性能 3、开启Spark的反压机制：，该参数会自动调优读取速率。但是如果设置了 或 ，那么最后到底接收多少数据取决于三者的最小值

• 消费kafka时，读取消息报错：OffsetOutOfRangeException

• 原因：读取的offsetRange超出了Kafka的消息范围，如果是小于也就是kafka保存的消息已经被处理掉了（log.re）。或者超出Kafka现有的offset
• 解决方法：在读取offset时先进行校正，拿到offset的earliestOffset 和lastestOffset

• Kafka抖动导致No leader found

• kafka变更或者其他原因导致
• 解决方法：设置 大于1

未完待续。