西乡网站的建设,福田我要做网站优化比较好,深圳龙岗招聘设计,四合一网站建设简介#xff1a; 本文主要讲解MaxCompute Spark资源调优#xff0c;目的在于在保证Spark任务正常运行的前提下#xff0c;指导用户更好地对Spark作业资源使用进行优化#xff0c;极大化利用资源#xff0c;降低成本。
本文作者#xff1a;吴数傑 阿里云智能 开发工程师 …简介 本文主要讲解MaxCompute Spark资源调优目的在于在保证Spark任务正常运行的前提下指导用户更好地对Spark作业资源使用进行优化极大化利用资源降低成本。
本文作者吴数傑 阿里云智能 开发工程师
1. 概述
本文主要讲解MaxCompute Spark资源调优目的在于在保证Spark任务正常运行的前提下指导用户更好地对Spark作业资源使用进行优化极大化利用资源降低成本。 2. Sensor
Sensor提供了一种可视化的方式监控运行中的Spark进程每个workerExecutor及masterDriver都具有各自的状态监控图可以通过Logview中找到入口如下图所示 打开Sensor之后可以看到下图提供了Driver/Executor在其生命周期内的CPU和内存的使用情况
cpu_plan/mem_plan蓝线代表了用户申请的CPU和内存计划量 用户可以直观地从cpu_usage图中看出任务运行中的CPU利用率mem_usage代表了任务运行中的内存使用是mem_rss和page cache两项之和详见下文Memory Metrics
mem_rss 代表了进程所占用了常驻内存这部分内存也就是Spark任务运行所使用的实际内存通常需要用户关注如果该内存超过用户申请的内存量就可能会发生OOM导致Driver/Executor进程终止。此外该曲线也可以用于指导用户进行内存优化如果实际使用量远远小于用户申请量则可以减少内存申请极大化利用资源降低成本。 mem_cachepage_cache用于将磁盘中的数据缓存到内存中从而减少磁盘I/O操作通常由系统进行管理如果物理机内存充足那么mem_cache可能会使用很多用户可以不必关心该内存的分配和回收。3. 资源参数调优
1Executor Cores
相关参数spark.executor.cores
每个Executor的核数即每个Executor中的可同时运行的task数目 Spark任务的最大并行度是num-executors * executor-coresSpark任务执行的时候一个CPU core同一时间最多只能执行一个Task。如果CPU core数量比较充足通常来说可以比较快速和高效地执行完这些Task。同时也要注意每个Executor的内存是多个Task共享的如果单个Executor核数太多内存过少那么也很可能发生OOM。
2Executor Num
相关参数spark.executor.instances
该参数用于设置Spark作业总共要用多少个Executor进程来执行 通常用户可以根据任务复杂度来决定到底需要申请多少个Executor此外需要注意如果出现Executor磁盘空间不足或者部分Executor OOM的问题可以通过减少单个Executor的cores数增加Executor的instances数量来保证任务总体并行度不变同时降低任务失败的风险。
3Executor Memory
相关参数spark.executor.memory
该参数用于设置每个Executor进程的内存。Executor内存的大小很多时候直接决定了Spark作业的性能而且JVM OOM在Executor中更为常见。相关参数2spark.executor.memoryOverhead
设置申请Executor的堆外内存主要用于JVM自身字符串, NIO Buffer等开销注意memoryOverhead 这部分内存并不是用来进行计算的用户代码及spark都无法直接操作。 如果不设置该值那么默认为spark.executor.memory * 0.10最小为384 MB
Executor 内存不足的表现形式
在Executor的日志Logview-某个Worker-StdErr中出现Cannot allocate memory在任务结束的Logview result的第一行中出现The job has been killed by OOM Killer, please check your jobs memory usage.在Sensor中发现内存使用率非常高在Executor的日志中出现java.lang.OutOfMemoryError: Java heap space在Executor的日志中出现GC overhead limit exceededSpark UI中发现频繁的GC信息可能出现OOM的间接表现形式部分Executor出现No route to host: workerd********* / Could not find CoarseGrainedScheduler等错误
可能原因及解决方案
限制executor 并行度将cores 调小多个同时运行的 Task 会共享一个Executor 的内存使得单个 Task 可使用的内存减少调小并行度能缓解内存压力增加单个Executor内存 增加分区数量减少每个executor负载考虑数据倾斜问题因为数据倾斜导致某个 task 内存不足其它 task 内存足够如果出现了上文所述的Cannot allocate memory或The job has been killed by OOM Killer, please check your jobs memory usage这种情况通常是由于系统内存不足可以适当增加一些堆外内存来缓解内存压力通常设置spark.executor.memoryOverhead为1g/2g就足够了
4Driver Cores
相关参数spark.driver.cores
通常Driver Cores不需要太大但是如果任务较为复杂如Stage及Task数量过多或者Executor数量过多Driver需要与每个Executor通信并保持心跳在Sensor中看到Cpu利用率非常高那么可能需要适当调大Driver Cores 另外要注意在Yarn-Cluster模式运行Spark任务不能直接在代码中设置Driver的资源配置core/memory因为在JVM启动时就需要该参数因此需要通过--driver-memory命令行选项或在spark-defaults.conf文件/Dataworks配置项中进行设置。
5Driver Memory
相关参数1spark.driver.memory
设置申请Driver的堆内内存与executor类似相关参数2spark.driver.maxResultSize代表每个Spark的action例如collect的结果总大小的限制默认为1g。如果总大小超过此限制作业将被中止如果该值较高可能会导致Driver发生OOM因此用户需要根据作业实际情况设置适当值。相关参数3spark.driver.memoryOverhead设置申请Driver的堆外内存与executor类似Driver的内存通常不需要太大如果Driver出现内存不足通常是由于Driver收集了过多的数据如果需要使用collect算子将RDD的数据全部拉取到Driver上进行处理那么必须确保Driver的内存足够大。表现形式Spark应用程序无响应或者直接停止 在Driver的日志Logview-Master-StdErr中发现了Driver OutOfMemory的错误Spark UI中发现频繁的GC信息在Sensor中发现内存使用率非常高在Driver的日志中出现Cannot allocate memory
可能原因及解决方案代码可能使用了collect操作将过大的数据集收集到Driver节点在代码创建了过大的数组或者加载过大的数据集到Driver进程汇总SparkContextDAGScheduler都是运行在Driver端的。对应rdd的Stage切分也是在Driver端运行如果用户自己写的程序有过多的步骤切分出过多的Stage这部分信息消耗的是Driver的内存这个时候就需要调大Driver的内存。有时候如果stage过多Driver端甚至会有栈溢出
6本地磁盘空间
相关参数spark.hadoop.odps.cupid.disk.driver.device_size
该参数代表为单个Driver或Executor申请的磁盘空间大小默认值为20g最大支持100g Shuffle数据以及BlockManager溢出的数据均存储在磁盘上
磁盘空间不足的表现形式
在Executor/Driver的日志中发现了No space left on device错误解决方案最简单的方法是直接增加更多的磁盘空间调大spark.hadoop.odps.cupid.disk.driver.device_size 如果增加到100g之后依然出现该错误可能是由于存在数据倾斜shuffle或者cache过程中数据集中分布在某些block也可能是单个Executor的shuffle数据量确实过大可以尝试
对数据重分区解决数据倾斜问题 增加executor的数量spark.executor.instances需要注意缩小读表并发spark.hadoop.odps.input.split.size缩小单个Executor的任务并发spark.executor.cores同样由于在JVM启动前就需要挂载磁盘因此该参数必须配置在spark-defaults.conf文件或者dataworks的配置项中不能配置在用户代码中 此外需要注意该参数的单位为g不能省略g很多时候由于用户配置位置有误或者没有带单位g导致参数实际并没有生效任务运行依然失败
4. 总结
上文主要介绍了MaxCompute Spark在使用过程中可能遇到的资源不足的问题及相应的解决思路为了能够最大化利用资源首先建议按照1: 4的比例来申请单个worker资源即1 core: 4 gb memory如果出现OOM那么需要查看日志及Sensor对问题进行初步定位再进行相应的优化和资源调整。不建议单个Executor Cores 设置过多通常单个Executor在2-8 core是相对安全的如果超过8那么建议增加instance数量。适当增加堆外内存为系统预留一些内存资源也是一个常用的调优方法通常在实践中可以解决很多OOM的问题。最后用户可以参考官方文档https://spark.apache.org/docs/2.4.5/tuning.html包含更多的内存调优技巧如gc优化数据序列化等。
原文链接
本文为阿里云原创内容未经允许不得转载。
