zoukankan      html  css  js  c++  java
  • spark on yarn 资源调度(cdh为例)

    一、CPU配置:

        ApplicationMaster 虚拟 CPU内核

     yarn.app.mapreduce.am.resource.cpu-vcores   


       ApplicationMaster占用的cpu内核数(Gateway--资源管理 )

      //一般设置1个核,如果想启动时候快一点可以多设置核数,但它不管资源分配,所以只要保证任务执行过程中不挂就可以了

       容器虚拟 CPU内核

    yarn.nodemanager.resource.cpu-vcores

    //单 个NodeManager 最大能分配的cpu核数 (NodeManager --资源管理 )   

    因为所有该机器上的所有进程需要资源都向nodemanager申请资源,所以nodemanager设置为机器 最大能分配的核数,除非该机器上还有别的进程需要运行,且不是通过yarn进行资源调度。

     结论:当前 nodemanager申请的 ApplicationMaster数总和小于nodemanager最大cpu内核数

     
    Yarn 集群参数调优

      二、内存配置:

     container容器内存

    yarn.nodemanager.resource.memory-mb    

    //单个NodeManager能分配的最大内存(NodeManager --资源管理)

    //Memory Total = 单个NodeManager内存 * 节点数

     结论:提交任务占用内存Memory Used小于Memory Total

     Map 任务内存

     mapreduce.map.memory.mb


    //为作业的每个 Map 任务分配的物理内存量  (Gateway--资源管理 )   

         结论:map或reduce的内存需求不大于appmaster的内存需求

        

       最大容器内存

    yarn.scheduler.maximum-allocation-mb

     //单个任务可申请最大内存 (ResourceManager--资源管理 )

     

    Yarn 集群参数调优(以CDH集群为例)

      三、同一个Map或者Reduce并行执行:

      Map 任务推理执行(如果一个map任务执行特别慢,yarn会在其他机器上启动一个一模一样的map任务,yarn会看谁先执行完成,然后把其他一个任务关掉)

    mapreduce.map.speculative       //Gateway

       Reduce 任务推理执行

    mapreduce.reduce.speculative    //Gateway    


      四、spark加日志查看(旧版本)

       编辑 spark-defaults.conf

     

     spark.yarn.historyServer.address=http://hostname:18088/

      五、JVM重用

        启用 Ubertask优化:

     mapreduce.job.ubertask.enable | (默认false)     //true则表示启用jvm重用(Gateway--性能 )


    资源参数调优
      了解完了Spark作业运行的基本原理之后,对资源相关的参数就容易理解了。所谓的Spark资源参数调优,其实主要就是对Spark运行过程中各个使用资源的地方,通过调节各种参数,来优化资源使用的效率,从而提升Spark作业的执行性能。以下参数就是Spark中主要的资源参数,每个参数都对应着作业运行原理中的某个部分,我们同时也给出了一个调优的参考值。
     
    num-executors


      参数说明:该参数用于设置Spark作业总共要用多少个Executor进程来执行。Driver在向YARN集群管理器申请资源时,YARN集群管理器会尽可能按照你的设置来在集群的各个工作节点上,启动相应数量的Executor进程。这个参数非常之重要,如果不设置的话,默认只会给你启动少量的Executor进程,此时你的Spark作业的运行速度是非常慢的。

      参数调优建议:每个Spark作业的运行一般设置50~100个左右的Executor进程比较合适,设置太少或太多的Executor进程都不好。设置的太少,无法充分利用集群资源;设置的太多的话,大部分队列可能无法给予充分的资源。
     
    executor-memory


      参数说明:该参数用于设置每个Executor进程的内存。Executor内存的大小,很多时候直接决定了Spark作业的性能,而且跟常见的JVM OOM异常,也有直接的关联。

      参数调优建议:每个Executor进程的内存设置4G~8G较为合适。但是这只是一个参考值,具体的设置还是得根据不同部门的资源队列来定。可以看看自己团队的资源队列的最大内存限制是多少,num-executors乘以executor-memory,就代表了你的Spark作业申请到的总内存量(也就是所有Executor进程的内存总和),这个量是不能超过队列的最大内存量的。此外,如果你是跟团队里其他人共享这个资源队列,那么申请的总内存量最好不要超过资源队列最大总内存的1/3~1/2,避免你自己的Spark作业占用了队列所有的资源,导致别的同学的作业无法运行。
     
    executor-cores


      参数说明:该参数用于设置每个Executor进程的CPU core数量。这个参数决定了每个Executor进程并行执行task线程的能力。因为每个CPU core同一时间只能执行一个task线程,因此每个Executor进程的CPU core数量越多,越能够快速地执行完分配给自己的所有task线程。

      参数调优建议:Executor的CPU core数量设置为2~4个较为合适。同样得根据不同部门的资源队列来定,可以看看自己的资源队列的最大CPU core限制是多少,再依据设置的Executor数量,来决定每个Executor进程可以分配到几个CPU core。同样建议,如果是跟他人共享这个队列,那么num-executors * executor-cores不要超过队列总CPU core的1/3~1/2左右比较合适,也是避免影响其他同学的作业运行。
     
    driver-memory


      参数说明:该参数用于设置Driver进程的内存。

      参数调优建议:Driver的内存通常来说不设置,或者设置1G左右应该就够了。唯一需要注意的一点是,如果需要使用collect算子将RDD的数据全部拉取到Driver上进行处理,那么必须确保Driver的内存足够大,否则会出现OOM内存溢出的问题。
     

    spark.default.parallelism

      参数说明:该参数用于设置每个stage的默认task数量。这个参数极为重要,如果不设置可能会直接影响你的Spark作业性能。

      参数调优建议:Spark作业的默认task数量为500~1000个较为合适。很多同学常犯的一个错误就是不去设置这个参数,那么此时就会导致Spark自己根据底层HDFS的block数量来设置task的数量,默认是一个HDFS block对应一个task。通常来说,Spark默认设置的数量是偏少的(比如就几十个task),如果task数量偏少的话,就会导致你前面设置好的Executor的参数都前功尽弃。试想一下,无论你的Executor进程有多少个,内存和CPU有多大,但是task只有1个或者10个,那么90%的Executor进程可能根本就没有task执行,也就是白白浪费了资源!因此Spark官网建议的设置原则是,设置该参数为num-executors * executor-cores的2~3倍较为合适,比如Executor的总CPU core数量为300个,那么设置1000个task是可以的,此时可以充分地利用Spark集群的资源。
     

    spark.storage.memoryFraction


      参数说明:该参数用于设置RDD持久化数据在Executor内存中能占的比例,默认是0.6。也就是说,默认Executor 60%的内存,可以用来保存持久化的RDD数据。根据你选择的不同的持久化策略,如果内存不够时,可能数据就不会持久化,或者数据会写入磁盘。

      参数调优建议:如果Spark作业中,有较多的RDD持久化操作,该参数的值可以适当提高一些,保证持久化的数据能够容纳在内存中。避免内存不够缓存所有的数据,导致数据只能写入磁盘中,降低了性能。但是如果Spark作业中的shuffle类操作比较多,而持久化操作比较少,那么这个参数的值适当降低一些比较合适。此外,如果发现作业由于频繁的gc导致运行缓慢(通过spark web ui可以观察到作业的gc耗时),意味着task执行用户代码的内存不够用,那么同样建议调低这个参数的值。
     

    spark.shuffle.memoryFraction


      参数说明:该参数用于设置shuffle过程中一个task拉取到上个stage的task的输出后,进行聚合操作时能够使用的Executor内存的比例,默认是0.2。也就是说,Executor默认只有20%的内存用来进行该操作。shuffle操作在进行聚合时,如果发现使用的内存超出了这个20%的限制,那么多余的数据就会溢写到磁盘文件中去,此时就会极大地降低性能。

      参数调优建议:如果Spark作业中的RDD持久化操作较少,shuffle操作较多时,建议降低持久化操作的内存占比,提高shuffle操作的内存占比比例,避免shuffle过程中数据过多时内存不够用,必须溢写到磁盘上,降低了性能。此外,如果发现作业由于频繁的gc导致运行缓慢,意味着task执行用户代码的内存不够用,那么同样建议调低这个参数的值
    资源参数的调优,没有一个固定的值,需要同学们根据自己的实际情况(包括Spark作业中的shuffle操作数量、RDD持久化操作数量以及spark web ui中显示的作业gc情况),同时参考本篇文章中给出的原理以及调优建议,合理地设置上述参数。

     

    Executor的内存主要分为三块:第一块是让task执行我们自己编写的代码时使用,默认是占Executor总内存的20%;第二块是让task通过shuffle过程拉取了上一个stage的task的输出后,进行聚合等操作时使用,默认也是占Executor总内存的20%;第三块是让RDD持久化时使用,默认占Executor总内存的60%。



    提交spark :

    #!/bin/bash
    source /etc/profile
    export LANG=zh_CN.UTF-8
    
    
    year=`date -d "yesterday" +%Y`
    month=`date -d "yesterday" +%m`
    day=`date -d "yesterday" +%d`
    
    
    SPARK_MASTER=spark://10.110.79.2:7077
    SPARK_DEPLOY="--master yarn --deploy-mode cluster"
    #SPARK_RESOURCE="--executor-memory 45G --executor-cores 4"
    SPARK_RESOURCE="--num-executors 4"
    SCRIPT_PATH="/opt/shell/log"
    LOG_PATH="/app/log"
    cluster1="hdfs://logcluster2"
    jarname=/opt/shell/log/lib/leagsoft-1.0-SNAPSHOT-jar-with-dependencies.jar
    inputDir=/leagsoft
    outputMysqlDir=/model/leagsoft_user/mysql
    outputESDir=/model/leagsoft_user/es
    LOG_FILE="${LOG_PATH}/module/leagsoft/user/log_2hdfs_`date +%Y%m%d`"
    
    
    echo "#spark leagsoftUserInfo2hdfsAndES `date '+%Y-%m-%d %H:%M:%S'`" >> ${LOG_FILE}
    
    
    hadoop fs -test -e "${inputDir}/${year}/${month}/${day}"
    if [ $? -eq 0 ] ; then
    
    
    spark-submit ${SPARK_DEPLOY}  ${SPARK_RESOURCE} 
    --queue infrastructure 
    --executor-memory 10G 
    --executor-cores 2               
    --class  com.express.sf.leagsoft.leagsoft_user 
    --conf spark.default.parallelism=16 
    --conf spark.shuffle.consolidateFiles=true 
    --conf "spark.es.nodes=10.110.77.48" 
    --conf "spark.es.port=9200" 
    --conf "spark.es.index.auto.create=true" 
    --conf "spark.es.batch.size.entries=50000" 
    --conf spark.kryoserializer.buffer.max=64mb 
    --conf spark.kryoserializer.buffer=256 
     "${jarname}" 
    ${cluster1}${inputDir}/$year/$month/$day  ${cluster1}${outputESDir}/$year/$month/$day ${cluster1}${outputMysqlDir}/$year/$month/$day
    
    
    ret=$?
    fi
    
    echo "#结束 `date '+%Y-%m-%d %H:%M:%S'`" >> ${LOG_FILE}
    exit $ret



    注意,有些参数是和运行模式有关系的,比如  total-executor-cores  只对standalone和Mesos模式起作用,对cluster模式不起作用

    参数解释

    --queue infrastructure 

    提交到yarn 上使用的资源队列,默认是default,这里使用infrastructure ,资源对列在hadoop中设置,详见http://blog.csdn.net/cottonduke/article/details/60576545
    ---------------------
    作者:YiRan_Zhao
    来源:CSDN
    原文:https://blog.csdn.net/yiran_zhao/article/details/81089248
    版权声明:本文为博主原创文章,转载请附上博文链接!

  • 相关阅读:
    类风湿性关节炎患者肿瘤坏死因子拮抗剂应用和心血管疾病的风险:系统文献复习
    合用DMARDs对持续抗TNF治疗的类风湿关节炎患者的影响:来自英国风湿病生物制剂注册系统的结果
    依那西普治疗幼年型特发性关节炎患者的疗程和停药原因
    TNF治疗早期类风湿关节炎患者严重感染和恶性肿瘤的风险: 随机对照研究的荟萃分析
    生物制剂对银屑病关节炎中轴表现的疗效:对依那西普治疗的一组患者为期12个月的观察性研究
    中国银屑病患者中银屑病关节炎的患病率和特征
    TNF抑制剂在10例新近起病的难治性反应性关节炎患者中的安全性与疗效
    中信国健临床通讯2011年1月第2期目录
    甲氨蝶呤治疗早期未用过DMARD的类风湿性关节炎的疗效预测:来自SWEFOT试验开放期初期的结果
    TopCoder入门教程 sqybi完善版[转载]
  • 原文地址:https://www.cnblogs.com/gxc2015/p/10109641.html
Copyright © 2011-2022 走看看