Spark性能测试工具

 
 

  
  
Spark 性能优化方案
  
  

  
  
Spark性能测试工具

  
  
•Spark性能测试基准程序Benchmark
  
  
–https://github.com/intel-hadoop/HiBench
  
  
•Spark性能测试与分析可视化工具
  
  
–https://github.com/zhihuili/Dew
  
  

  
  
性能调优的步骤


  
  
1.性能测试，观察系统性能特性
  
  
2.资源（CPU、Memory、Disk、Net）利用分析，寻找资源瓶颈，提高资源利用
  
  
3.系统架构、代码分析，发现资源利用关键所在
  
  
4.代码、架构、基础设施调优，优化、平衡资源利用
  
  
5.性能测试，观察系统性能特性
  
  

  
  
1. Spark任务文件初始化调优

  
  
资源分析，发现第一个stage时间特别长，耗时长达14s，CPU和网络通信都有一定开销，不符合应用代码逻辑。
  
  
•打开Spark作业log，分析这段时间的Spark运行状况。

  
  
•根据log分析结果，阅读Spark相关源码。
  
  
•发现Spark在任务初始化加载应用代码的时候，每个Executor都加载一次应用代码，当时每台服务器最多可启动48个Executor，每个应用代码包17M大小，导致加载开销巨大。
  
  
•优化方案：Executor加载应用程序包启用本地文件缓存模式。[SPARK-2713]

  
  
•优化效果：Stage1运行时间从14s下降到不到1s。
  
  
2.Spark任务调度优化

  
  
.资源分析，发现stage2只有一台服务器上的CPU被使用，其他服务器CPU完全空闲。
  
  
•打开Spark作业log，分析这段时间的Spark运行状况。

  
  
•根据log分析结果，阅读Spark相关源码。
  
  
•通过源码发现，Spark Driver在任务分配的时候，仅针对当前已经向Driver注册过的Executor进行任务分配，而Executor的注册是有先后的，如果第一个job的任务数比较少，就会出现第一个Worker的Executor注册的时候将所有任务领走的情况。
  
  
3.任务分配算法调优

  
  
.在做log分析的时候，发现在Executor领取任务的时候，在最后总会有一两个Executor领取的任务是非local的。比如，最后两个任务A[2,3,1]和B[1,3,4]，Executor[1][2]，当Executor[1]领取了任务A，则Executor[2]领到的任务B就是非local的。
  
  
.解决方案：对任务进行偏序排序后再分配[SPARK-2193]
  
  
4.OS配置调优

  
  
.资源分析，发现服务器大量CPU资源消耗为sys类型
  
  
.调查发现，是因为某些Linux版本的transparent hugepage默认为enable状态导致
  
  
.优化方案：关闭OS的transparenthugepages
  
  
–Echo never > /sys/kernel/mm/transparent_hugepage/enabled
  
  
–Echo never > /sys/kernel/mm/ transparent_hugepage/defrag
  
  
5.网卡调优

  
  
•资源分析，发现大量作业时间消耗在网络传输上。
  
  
•解决方案：网卡带宽从1G升级到10G
 
 

作者：严国华
链接：http://www.jianshu.com/p/4bada19ddd70
來源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。