yarn一些最佳配置

yarn一些最佳配置

合理设置队列名

mapreduce.job.queuename
设置队列名
map读取时进行小文件整合

    mapreduce.input.fileinputformat.split.minsize
    mapreduce.input.fileinputformat.split.maxsize
    mapreduce.input.fileinputformat.split.minsize.per.node
    mapreduce.input.fileinputformat.split.minsize.per.rack

mapreduce中map的个数和两个有关,一个是文件的个数,一个是大小,默认split是128M, 如果一个文件大于128M,例如129M,那么会有两个map,一个是128M,一个是1M。
又例如有10个文件,每个都是1M,那么map是会有10个的。
对于这种小文件太多,或者是我们想讲每一个map处理的数据量大一些,就应该设置上面的几个参数,上面几个参数是byte的单位。
例如我们想设置一次处理1G,那么就设置成

mapreduce.input.fileinputformat.split.minsize = 1024*1024*1024
mapreduce.input.fileinputformat.split.maxsize = 1024*1024*1024
mapreduce.input.fileinputformat.split.minsize.per.node = 1024*1024*1024
mapreduce.input.fileinputformat.split.minsize.per.rack = 1024*1024*1024

值得注意的是,conf中最好设置一个如下参数,mapreduce默认的mapreduce.job.max.split.locations为10个,意味着如果一个map处理的split的文件超过了10个节点,那么就会有数据截取,导致程序报错

conf.setInt(“mapreduce.job.max.split.locations”, 1000);

推测功能

mapreduce.reduce.speculative
默认是true,有时候需要设置成false。
参考: http://itfish.net/article/60389.html或者搜索
container大小设置最佳实践

mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb 和mapreduce.map.cpu.vcores和 mapreduce.reduce.cpu.vcores

mapreduce.map.memory.mb 默认1024M,一个map启动的container是1024M
mapreduce.reduce.memory.mb 默认3072M,一个map启动的container是3072
mapreduce.map.cpu.vcores默认1个vcore,一个map任务默认使用一个虚拟核运行
mapreduce.reduce.cpu.vcores默认1个vcore,一个reduce任务默认使用一个虚拟核运行。

调优就是尽可能的让集群资源充分利用,这里需要根据具体的需求和集群资源情况来定。
例如不考虑内存溢出等情况, 集群资源如下
Memory Total     VCores Total
320G     80

如果数据比较均匀,应该尽可能的设置成如下:
mapreduce.map.memory.mb     mapreduce.reduce.memory.mb     mapreduce.map.cpu.vcores     mapreduce.reduce.cpu.vcores
4096     4096     1     1

这样并发数能到

max(320G/4G,80vcore/1vcore)=80
上面是map核reduce都到了最大的80的并发,集群利用最充分。

一般来说,我们默认mapreduce.map.cpu.vcores和mapreduce.reduce.cpu.vcores为1个就好了,但是对于一个map和一个reduce的container的内存大小设置成了4G,如果一个map和一个reduce处理的任务很小,那又会很浪费资源,这时,对于map来说,可以用前面说的小文件整合,设置mapreduce.input.fileinputformat.split来解决map的大小,尽可能接近4G,但是又要注意可能出现的内存溢出的情况。
对于reduce,1个container启动用了4G内存,那这4G内存也应尽可能的充分使用,这时候,我们尽量的评估进入到reduce的数据大小有多少,合理的设置reduceTask数,这一步是比较麻烦的,因为这里如果出现数据倾斜将会导致oom内存溢出错误。

前面说到了,并发数受到集群总内存/container的限制,同时,并发数也会受到集群vcore的限制,还是上面那个例子,例如集群资源为320G,80vcore,我一个map任务为2G,由于受到cpu的限制,最多同时80个vcore的限制,那么内存使用只能使用160G。这显然是浪费资源了。

对于mapreduce.map.cpu.vcores和mapreduce.reduce.cpu.vcores,为什么默认是1呢,在集群的内存/cpu很小的情况下,能否一个map端将这两个值设置成2或者更大呢。这是当然可以的,但是,即使我们将这个设置成2,任务的并发并不会是 Vcores Total/2的关系,并发仍然将是上面两条决定的。举个例子,还是320G,80vcore集群。我们设置mapreduce.map.memory.mb为4G,mapreduce.map.cpu.vcores为2, 很多人以为我一个map需要两个核,那么80vcore/2vcore=40,那么我们并发最大只能用到40*4=160G的内存,其实这是错误的,这种情况,我们任然基本上能将内存占满,并发数任然能到80个。这个时候, mapreduce.map.cpu.vcores基本就失效了。后来仔细想了想,一个map或者reduce任务,里面的数据应该并不可能会有多线程并发,但是mapreduce.map.cpu.vcores为什么会有这个参数呢,后来想了一下,一个map或者reduce任务,代码的执行肯定是一个线程,但是任务的状态等监控,垃圾回收等,是可以使用另外一个线程来运行的,这也是将mapreduce.map.cpu.vcores设置成2可能会快一点的效果。
我曾经碰到一个cpu十分充足的集群,vcore和内存比例是1比1,但是为了让数据不倾斜,我们的mapreduce.reduce.memory.mb至少要到4G,那么这时候,其实cpu就只能利用1/4了,这时候cpu很充足,我便尝试将mapreduce.map.cpu.vcores设置成2.其实这样也并不是说我一定每个map都能使用到2个vcore,只不过有时候,有的任务状态监控,jvm垃圾回收等,就有了另外一个vcore来运行了。

mapreduce.map.cpu.vcores补充20180914, 这个参数貌似在公平队列是没用的,vCores用于较大的群集,以限制不同用户或应用程序的CPU。如果您自己使用YARN,则没有理由限制容器CPU。这就是为什么在Hadoop中默认甚至不考虑vCore的原因,capacity-schedule调度下才有用,之前对这个参数不了解,后来在StackOverflow提了一个问题才明白
https://stackoverflow.com/questions/51276027/whats-the-function-of-mapreduce-map-cpu-vcores
mapreduce.task.io.sort.mb

这个参数理解需要理解mapreduce的shuffle过程,mapreduce的shuffle中,有一个环形缓冲区(就是一个带有前后两个指针的数组,shuffle过程自行搜索),这个值默认是100兆,配合上有个参数mapreduce.task.io.sort.spill.percent,一般这个参数默认为0.8,那么就意味着,这个数组到了80M,我就要开始进行排序了,然后要往磁盘写数据了。所以这个值越大,就不用导致频繁的溢出了。
按照经验,一般这个值和map的输出,reduce的输入的大小相关比较好,但是这个值最好别超过2046,假如一个reduce处理的数据量为1G,那么这个值可以设置成200M, 一般的经验是reduce处理的数据量/5的关系比较好。
mapreduce.map.java.opts

就是一个map container中jvm虚拟机的内存
一般设置成mapreduce.map.memory.mb的0.8倍比较合适
例如mapreduce.map.memory.mb=4096
mapreduce.map.java.opts 设置成 -Xmx3276M
mapreduce.reduce.java.opts

就是一个reduce container中jvm虚拟机的内存
一般设置成mapreduce.reduce.memory.mb的0.8倍比较合适
例如mapreduce.reduce.memory.mb=4096
mapreduce.reduce.java.opts 设置成 -Xmx3276M
yarn.app.mapreduce.am.resource.mb

MR ApplicationMaster占用的内存量,具体设置TODO,记得有时候小文件太多,超过多少万,这个太小了任务不会运行
mapreduce.task.timeout

mapreduce任务默认超时时间,有时候抢队列的时候,这个会用上,默认值600000就好,不用管
mapred.max.map.failures.percent

允许map失败的比例,默认是0,可以根据自己需求,合理设置
mapred.max.reduce.failures.percent

允许reduce失败的比例,默认是0,可以根据自己需求,合理设置
mapreduce.job.reduce.slowstart.completedmaps

map不用跑完就可以开始reduce了的比例,默认是0.95(网上说的0.05感觉不对啊),也就是map完成到百分之95时就可以开始reduce了,这样的好处是到了map最后几个,其实大多数资源都空闲了,这时候就先进行reduce吧,不然等全部跑完map有点浪费资源了。
但是我之前碰到过一次资源死锁饿死的情况,就是map还有几个没跑完,reduce已经起来了,然而reduce需要等待map跑完的数据,reduce端拉不到,然后map端也没完成,并且整个集群的资源都被利用完了,这样map跑不完,reduce也跑不完,就这样相互等待卡着
HADOOP_CLIENT_OPTS

hadoop jar启动的时候,client端的jvm内存大小,太小会有问题,举个例子。太小的话,如果跑的文件个数比较多,JOB还未起来就会报OOM错误

hadoop-oom

此配置在hadoop-env.sh中

export HADOOP_CLIENT_OPTS=”-Xmx1024m” 

扩展 HIVE的一些常用设置

set mapreduce.job.queuename=default
set yarn.nodemanager.vmem-pmem-ratio=4.2;
set mapreduce.map.memory.mb=16384;
set mapred.map.java.opts = -Xmx13106M;
set mapred.map.child.java.opts=-Xmx13106M;
set hive.merge.mapredfiles=true;

set hive.exec.reducers.max=150;
set mapreduce.reduce.memory.mb=30240;
set mapreduce.reduce.java.opts= -Xmx24192m;
set mapreduce.task.io.sort.mb=1024;

set mapred.max.split.size=8036870912;
set mapred.min.split.size.per.node=1234217728;
set mapred.min.split.size.per.rack=1234217728;
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

我一般将这些设置放在一个目录下,保存为.hql文件,然后source这个文件即可

steven liu

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。

发布者:全栈程序员-用户IM,转载请注明出处:https://javaforall.cn/119653.html原文链接:https://javaforall.cn

【正版授权,激活自己账号】: Jetbrains全家桶Ide使用,1年售后保障,每天仅需1毛

【官方授权 正版激活】: 官方授权 正版激活 支持Jetbrains家族下所有IDE 使用个人JB账号...

(0)


相关推荐

  • 40-50岁的男人喜欢什么样的女人呢?

    40-50岁的男人喜欢什么样的女人呢?悟空问答里有个热门问题:40-50岁的男人喜欢什么样的女人呢?答案多姿多彩,有理有据互补的女人有安全感的女人经济独立的女人性爱和谐的女人心态成熟的女人知书达理的女人会过生活的女人能好好聊天的女人温柔体贴的女人…………认为:无论男人是20岁、30岁、40岁、50岁、60岁、70岁、80岁、90岁、100岁还是200岁,他们都喜欢年轻漂亮的小姑娘,同意的转起。

  • ISP举例_low input lag

    ISP举例_low input lag  从2000年9月底摄像头首次出现在手机上算起,到如今成为诸多智能设备不可或缺的一部分,便携式手机摄像头已经走过了18年的发展历程。随着手机智能化、轻薄化的发展进程,其搭载的摄像头也随之发生了变化,但基本结构并未有太大的改变。通常而言,一个摄像头硬件应包含以下五个部分:外壳(Housing)或者镜头固定物(LensHolder)、镜头(Lens)、红外截止滤波片(IR-cutfilter…

    2022年10月23日
  • 计算机实现原理专题–二进制减法器(二)

    计算机实现原理专题–二进制减法器(二)在计算机实现原理专题–二进制减法器(一)中说明了基本原理,现准备说明如何来实现。首先第一步255-b运算相当于对b进行按位取反,因此可将8个非门组成如下图的形式:由于每次做减法时,我们可以人为的判断被减数和减数的大小,所以当被减数大于减数时中间结果一定会上溢也就是多出1位,因此中…

  • 我的Android重构之旅:插件化篇

    我的Android重构之旅:插件化篇

  • Android中的跨进程通信方法实例及特点分析(二):ContentProvider

    Android中的跨进程通信方法实例及特点分析(二):ContentProvider

  • 用python随机生成数字_如何实现python随机生成数字?

    用python随机生成数字_如何实现python随机生成数字?今天小编就生成随机数,整理了多个方式,方便大家在项目时,根据自己的需求,直接拿来套用即可,以下内容相当详细,具体来看看吧~说明:python中生成随机数主要用到random模块,方法主要包括:randint、uniform、random、sample、choice等几种常用方法;环境:MacOS10.14.6/Windows10、python3.7.31、在[a,b]之间产生随机整数(ran…

    2022年10月23日

发表回复

您的电子邮箱地址不会被公开。

关注全栈程序员社区公众号