CDH集群调优:内存、Vcores和DRF
吐槽
最近“闲”来无事,通过CM把vcores使用情况调出来看了一眼,发现不论集群中有多少个任务在跑,已分配的VCores始终不会超过120。而集群的可用Vcores是360(15台机器×24虚拟核)。这就相当于CPU资源只用到了1/3,作为一个半强迫症患者绝对不能容忍这样的事情发生。
分析的过程不表,其实很简单就是几个参数的问题。本以为CM能智能的将这些东西配好,现在看来好像不行。以下记录结论。
DRF和相关参数
DRF: Dominant Resource Fairness,根据CPU和内存公平调度资源。CDH动态资源池默认采用的DRF计划策略。简单的理解就是内存不够的时候,多余的CPU就不会分配任务了,就让他空着;CPU不够的时候,多出来的内存也不会再启动任务了。
理解这个计划策略后,再查看Yarn启动任务时资源相关的参数,发现有以下几个参数可能会产生影响:
- mapreduce.map.memory.mb ,map任务内存,cdh默认1G
- mapreduce.map.cpu.vcores ,map任务虚拟CPU核数,cdh默认1
- mapreduce.reduce.memory.mb ,reduce任务内存,cdh默认1G
- mapreduce.reduce.cpu.vcores ,reduce任务虚拟CPU核数,cdh默认1
- yarn.nodemanager.resource.memory-mb ,容器内存,cdh默认8G
- yarn.nodemanager.resource.cpu-vcores ,容器虚拟CPU核数,cdh默认8,但CM会自动检测内核数并修改,我这里被自动改成了24。
可以看到默认配置下,CPU核数和内存是1:1G的比例来启动任务的。
接着查看了下分配给Yarn的内存,果然是8×15=120G,所以可用内存比可用vcores(360个)比起来就小太多了,导致按照1:1G的比例下最多只能使用120个vcores。
以上只是猜想。
测试
为了证实我的猜想,将 yarn.nodemanager.resource.memory-mb 调成了16G(咱内存128G,管够)。重启yarn后,再次启动MR,于是有了下图:
可以看到参数调整前,Yarn可用内存为120G,调整后变成了240G;vcores由调整前的120变成了240。至此,证明猜想正确。
所以对于这个集群来说,由于内存为128G,内核为24个,所以完全可以将 yarn.nodemanager.resource.memory-mb 参数调成24G,这样就能将所有的CPU都利用起来了。
测试结果
yarn.nodemanager.resource.memory-mb 为8G时:
Time taken: 3794.17 secondsTotal MapReduce CPU Time Spent: 3 days 10 hours 43 minutes 22 seconds 640 msec
yarn.nodemanager.resource.memory-mb 为16G时:
Time taken: 2077.138 secondsTotal MapReduce CPU Time Spent: 3 days 12 hours 55 minutes 43 seconds 210 msec
可以看到确实快了很多很多。(ps:两次跑的任务所用的数据不一样,以免缓存导致第二次跑相同的任务会速度比第一次快,但两次任务所用的数据量差不多,都在650G左右)
其它
查看VCores SQL
SELECT allocated_vcores_cumulative, available_vcores where category=YARN_POOL and serviceName="yarn" and queueName=root
查看分配给Yarn的内存 SQL
SELECT allocated_memory_mb_cumulative, available_memory_mb where category=YARN_POOL and serviceName="yarn" and queueName=root
当然最简单的查看方式就是在CM的“动态资源池”页面看。
转: http://blog.selfup.cn/1631.html?utm_source=tuicool&utm_medium=referral
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
2015-03-22 网易笔试(数据挖掘方向)——邮件事业部
答案正在更新,有想法的也可以留言............ 一:单选题 1:下列程序的输出结果为() #include <iostream.h> void main() { int n[][] = {10,20,30,40,50,60}; int (*p)[3]; p = n; cout<<[0][0] << "," <<*( p[0] + 1) << "," <<(*p)[2]<<endl; } A: 10,30,50 B: 10,20,30 C: 20,40,60 D: 10,30,60 解析: n[2][3] = { 10,20,30, 40,50,60 }; *( p[0] + 1) = p[i][j] (与此类似的形式还有 *( *( p+i ) + j )) 故等于20 (*p)[2]:*p指的是首行 2代表第三列 所以为 30 答案选B 2:存储以下数据,占用字节最多的是() A: 0 B: '0' C: " 0 " D: 0.0 解:int 在不同位数的计算机上表现出的长...
- 下一篇
分析从管理员角度对Hadoop进行调优
Hadoop管理员负责为用户作业提供一个高效的运行环境。管理员需要从全局出发,通过调整一些关键参数值提高系统的吞吐率和性能。总体上看,管理员需从硬件选择、操作系统参数调优、JVM参数调优和Hadoop参数调优等四个方面人手,为 Hadoop 用户提供一个高效的作业运行环境。 1.硬件选择 Hadoop自身架构的基本特点决定了其硬件配置的选型。Hadoop采用了master/slave架构,其中,master(JobTracker或者NameNode)维护了全局元数据信息,重要性远远大干 slave(TaskTracker或者DataNode)。在较低Hadoop版本中,master均存在单点故障问题,因此,master的配置应远远好于各个slave(TaskTracker或者DataNode),具体可参考Eric Sammer的《Hadoop Operations》 -书。 2.操作系统参数调优 由于Hadoop自身的一些特点,它只适合用于将Linux作为操作系统的生产环境。在实际应用场景中,管理员适当对Linux内核参数进行调优,可在一定程度上提高作业的运行效率,比较有用的调整选项如...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- MySQL8.0.19开启GTID主从同步CentOS8
- Linux系统CentOS6、CentOS7手动修改IP地址
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS8编译安装MySQL8.0.19
- SpringBoot2整合Redis,开启缓存,提高访问速度
- 设置Eclipse缩进为4个空格,增强代码规范
- CentOS7,CentOS8安装Elasticsearch6.8.6
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作