转自:http://blog.csdn.net/lsshlsw/article/details/49155087
Master默认使用512M内存,当集群中运行的任务特别多时,就会挂掉,原因是master会读取每个task的event log日志去生成spark ui,内存不足自然会OOM,可以在master的运行日志中看到,通过HA启动的master自然也会因为这个原因失败。
增加Master的内存占用,在Master节点spark-env.sh
中设置:
减少保存在Master内存中的作业信息
有时候我们还会在web ui中看到worker节点消失或处于dead状态,在该节点运行的任务则会报各种 lost worker
的错误,引发原因和上述大体相同,worker内存中保存了大量的ui信息导致gc时失去和master之间的心跳。
增加Master的内存占用,在Worker节点spark-env.sh
中设置:
减少保存在Worker内存中的Driver,Executor信息
Spark Shuffle FetchFailedException解决方案
missing output location
shuffle fetch faild
当前的配置为每个executor使用1core,5GRAM,启动了20个executor
这种问题一般发生在有大量shuffle操作的时候,task不断的failed,然后又重执行,一直循环下去,直到application失败。
一般遇到这种问题提高executor内存即可,同时增加每个executor的cpu,这样不会减少task并行度。
启动的execuote数量为:7个
每个executor的配置:
消耗的内存资源为:105G RAM
可以发现使用的资源并没有提升,但是同样的任务原来的配置跑几个小时还在卡着,改了配置后几分钟就能完成。
executor lost
task lost
各种timeout
由网络或者gc引起,worker或executor没有接收到executor或task的心跳反馈。
提高 spark.network.timeout
的值,根据情况改成300(5min)或更高。
默认为 120(120s),配置所有网络传输的延时,如果没有主动设置以下参数,默认覆盖其属性
数据倾斜
任务倾斜
差距不大的几个task,有的运行速度特别慢。
大多数任务都完成了,还有那么一两个任务怎么都跑不完或者跑的很慢,分为数据倾斜和task倾斜两种。
数据倾斜
数据倾斜大多数情况是由于大量的无效数据引起,比如null或者”“,也有可能是一些异常数据,比如统计用户登录情况时,出现某用户登录过千万次的情况,无效数据在计算前需要过滤掉。
数据处理有一个原则,多使用filter,这样你真正需要分析的数据量就越少,处理速度就越快。
具体可参考:
解决spark中遇到的数据倾斜问题
任务倾斜
task倾斜原因比较多,网络io,cpu,mem都有可能造成这个节点上的任务执行缓慢,可以去看该节点的性能监控来分析原因。以前遇到过同事在spark的一台worker上跑R的任务导致该节点spark task运行缓慢。
或者可以开启spark的推测机制,开启推测机制后如果某一台机器的几个task特别慢,推测机制会将任务分配到其他机器执行,最后Spark会选取最快的作为最终结果。
堆内存溢出
内存不够,数据太多就会抛出OOM的Exeception,主要有driver OOM和executor OOM两种
driver OOM
一般是使用了collect操作将所有executor的数据聚合到driver导致。尽量不要使用collect操作即可。
executor OOM
可以按下面的内存优化的方法增加code使用内存空间
spark.executor.memory
的值如果你在worker中调用了driver中定义的一些变量,Spark就会将这些变量传递给Worker,这些变量并没有被序列化,所以就会看到如上提示的错误了。
除了上文的map,还有filter,foreach,foreachPartition等操作,还有一个典型例子就是在foreachPartition中使用数据库创建连接方法。这些变量没有序列化导致的任务报错。
下面提供三种解决方法:
sparkConf
,SparkContext
,都用 @transent
进行注解,表示这些变量不需要被序列化spark.driver.maxResultSize默认大小为1G 每个Spark action(如collect)所有分区的序列化结果的总大小限制,简而言之就是executor给driver返回的结果过大,报这个错说明需要提高这个值或者避免使用类似的方法,比如countByValue,countByKey等。
将值调大即可
这个WARN可能还会导致ERROR
如果你比较了解spark中的stage是如何划分的,这个问题就比较简单了。
一个Stage中包含的task过大,一般由于你的transform过程太长,因此driver给executor分发的task就会变的很大。
所以解决这个问题我们可以通过拆分stage解决。也就是在执行过程中调用cache.count
缓存一些中间数据从而切断过长的stage。
driver did not authorize commit
driver节点内存不足
driver内存不足导致无法启动application,将driver分配到内存足够的机器上或减少driver-memory
os::commit_memory(0x0000000680000000, 4294967296, 0) failed;
error=’Cannot allocate memory’ (errno=12)
hdfs空间不够
hdfs空间不足,event_log无法写入,所以 ListenerBus会报错
,增加hdfs空间(删除无用数据或增加节点)
spark编译包与hadoop版本不一致
下载对应hadoop版本的spark包或自己编译。
driver机器端口使用过多
在一台机器上没有指定端口的情况下,提交了超过15个任务。
提交任务时指定app web ui端口号解决:
中文乱码
使用write.csv等方法写出到hdfs的文件,中文乱码。JVM使用的字符集如果没有指定,默认会使用系统的字符集,因为各个节点系统字符集并不都是UTF8导致,所以会出现这个问题。直接给JVM指定字符集即可。
spark-defaults.conf
spark使用的python版本为2.7,centOS默认python版本为2.6,升级即可。
部分节点上有错误提示
新加的节点运维装2.7版本的python,python命令是正确的,python2.7却无法调用,只要改改环境变量就好了。
该pickle文件是在0.17版本的scikit-learn下训练出来的,有些机器装的是0.14版本,版本不一致导致,升级可解决,记得将老版本数据清理干净,否则会报各种Cannot import xxx
的错误。
方法1:
方法2:
有时候会发现部分executor并没有在执行任务,为什么呢?
(1) 任务partition数过少,
要知道每个partition只会在一个task上执行任务。改变分区数,可以通过 repartition
方法,即使这样,在 repartition
前还是要从数据源读取数据,此时(读入数据时)的并发度根据不同的数据源受到不同限制,常用的大概有以下几种:
(2) 数据本地性的副作用
taskSetManager在分发任务之前会先计算数据本地性,优先级依次是:
Spark会优先执行高优先级的任务,任务完成的速度很快(小于设置的spark.locality.wait时间),则数据本地性下一级别的任务则一直不会启动,这就是Spark的延时调度机制。
举个极端例子:运行一个count任务,如果数据全都堆积在某一台节点上,那将只会有这台机器在长期计算任务,集群中的其他机器则会处于等待状态(等待本地性降级)而不执行任务,造成了大量的资源浪费。
判断的公式为:
其中 curTime
为系统当前时间,lastLaunchTime
为在某优先级下最后一次启动task的时间
如果满足这个条件则会进入下一个优先级的时间判断,直到 any
,不满足则分配当前优先级的任务。
数据本地性任务分配的源码在 taskSetManager.scala
。
如果存在大量executor处于等待状态,可以降低以下参数的值(也可以设置为0),默认都是3s。
当你数据本地性很差,可适当提高上述值,当然也可以直接在集群中对数据进行balance。
有可能哪台worker节点出现了故障,task执行失败后会在该 executor
上不断重试,达到最大重试次数后会导致整个 application
执行失败,我们可以设置失败黑名单(task在该节点运行失败后会换节点重试),可以看到在源码中默认设置的是 0
,
在 spark-default.sh
中设置
当 task
在该 executor
运行失败后会在其它 executor
中启动,同时此 executor
会进入黑名单30s(不会分发任务到该executor)。
如果你的任务shuffle量特别大,同时rdd缓存比较少可以更改下面的参数进一步提高任务运行速度。
spark.storage.memoryFraction
- 分配给rdd缓存的比例,默认为0.6(60%),如果缓存的数据较少可以降低该值。
spark.shuffle.memoryFraction
- 分配给shuffle数据的内存比例,默认为0.2(20%)
剩下的20%内存空间则是分配给代码生成对象等。
如果任务运行缓慢,jvm进行频繁gc或者内存空间不足,或者可以降低上述的两个值。
"spark.rdd.compress","true"
- 默认为false,压缩序列化的RDD分区,消耗一些cpu减少空间的使用
mysql读取并发度优化
spark.default.parallelism
发生shuffle时的并行度,在standalone模式下的数量默认为core的个数,也可手动调整,数量设置太大会造成很多小任务,增加启动任务的开销,太小,运行大数据量的任务时速度缓慢。
spark.sql.shuffle.partitions
sql聚合操作(发生shuffle)时的并行度,默认为200,如果该值太小会导致OOM,executor丢失,任务执行时间过长的问题
相同的两个任务:
spark.sql.shuffle.partitions=300:
spark.sql.shuffle.partitions=500:
速度变快主要是大量的减少了gc的时间。
但是设置过大会造成性能恶化,过多的碎片task会造成大量无谓的启动关闭task开销,还有可能导致某些task hang住无法执行。
修改map阶段并行度主要是在代码中使用rdd.repartition(partitionNum)
来操作。
spark-sql join优化
map-side-join 关联优化
磁盘IO优化
kryo Serialization
Spark不同Cluster Manager下的数据本地性表现
spark读取hdfs数据本地性异常
编写Spark程序的几个优化点