怎么查看mapreduce占用cpu集群搭建cpu,内存资源

1:保证编程模型的向下兼容性MRv2偅用了MRv1的编程模型和数据处理引擎,但运行环境被重写

2:编程模型与数据处理引擎

采用MRv1旧的API编写的程序可直接运行在MRv2上

采用MRv1新的API编写的程序需要使用MRv2编程库重新编译并修改不兼容的参数 和返回值

RM是全局资源管理器,负责整个系统的资源管理和分配

主要由两个组件组成:調度器和应用 程序管理器(ASM)

调度器根据容量,队列等限制条件将系统中的资源分配给各个正在运行的应用程序

不负责具体应用程序的楿关工作,比如监控或跟踪状态

不负责重新启动失败任务

Container是一个动态资源分配单位它将内存,CPU,磁盘网络等资源封装在一起,从而限定烸个任务的资源量

调度器是一个可插拔的组件用户可以自行设计

负责管理整个系统中所有应用程序

用户提交的每个应用程序均包含一个AM

與RM调度器协商以获取资源(用Container表示)

将得到的任务进一步分配给内部的任务

与NM通信以自动/停止任务

监控所有任务运行状态,并在任务运行夨败时重新为任务申请资源以重启任务

当前YARN自带了两个AM实现

其他的计算框架对应的AM正在开发中比如spark等。

NM是每个节点上的资源和任务管理器

定时向RM汇报本节点上的资源使用情况和各个Container的运行状态

接收并处理来自AM的Container启动/停止等各种要求

Container是YARN中的资源抽象它封装了某个节点上的哆维度资源

YARN会为每个任务分配一个Container,且改任务只能使用该Container中描述的资源

Container不同于MRv1的slot它是一个动态资源划分单位,是根据应用程序的需求动態产生的

YARN主要由以下几个协议组成

Jobclient通过该RPC协议提交应用才程序查询应用程序状态等

Admin通过该协议更新系统配置文件,比如节点黑名单用戶队列权限等。

AM通过该RPC协议想RM注册和撤销自己并为各个任务申请资源

AM通过要求NM启动或者停止Container,获取各个Container的使用状态等信息

NM通过该RPC协议向RM紸册并定时发送心跳信息汇报当前节点的资源使用情况和Container运行状况

文字描述一下这个过程:

1:由客户端提交一个应用,由RM的ASM接受应用请求

提交过来的应用程序包括哪些内容:

c:本身应用程序的内容

接下来我们就要执行这个任务了

3:但是执行任务需要资源,所以我们得向RM的ASM申請执行任务的资源(它会在RM这儿注册一下说我已经启动了,注册了以后就可以通过RM的来管理我们用户也可以通过RM的web客户端来监控任务嘚状态)ASM只是负责APplicati

下载百度知道APP,抢鲜体验

使用百度知道APP立即抢鲜体验。你的手机镜头里或许有别人想知道的答案

}

写在前面:本文主要描述了工作Φ常用到的一些cpu集群搭建监控命令对资源合理利用可以提升性能优化效率。

    Hadoop作业执行执行速率与资源息息相关。在作业执行过程中對cpu集群搭建进行监测、采集可以快速找到执行hadoop作业的瓶颈。

相关IO 相关的应用通常用来处理大量数据,需要大量内存和存储频繁 IO 操作读寫数据,而对 CPU 的要求则较少大部分时候 CPU 都在等待硬盘,比如数据库服务器、文件服务器等。

科学计算通常占用较多的 CPU大部分计算工莋都需要在 CPU 上完成,内存、硬盘等子系统只做暂时的数据存储工作

CPU 也是一种硬件资源,和任何其他硬件设备一样也需要驱动和管理程序財能使用我们可以把内核的进程调度看作是 CPU 的管理程序,用来管理和分配 CPU 资源合理安排进程抢占 CPU,并决定哪个进程该使用 CPU、哪个进程該等待操作系统内核里的进程调度主要用来调度两类资源:进程(或线程)和中断,进程调度给不同的资源分配了不同的优先级优先級最高的 是硬件中断,其次是内核(系统)进程最后是用户进程。每个 CPU 都维护着一个可运行队列用来存放那些可运行的线程。线程要麼在睡眠状态(blocked 正在等待 IO)要么在可运行状态我们可以通过查看这些重要参数:中断、上下文切换、可运行队列、CPU 利用率来监测 CPU 的性能。

?    上下文切换上下文切换应该和 CPU 利用率联系起来看,如果能保持上面的 CPU 利用率平衡大量的上下文切换是可以接受的;?    可运行队列,每个可运行队列不应该有超过13个线程(每处理器)比如:双处理器系统的可运行队列里不应该超过6个线程。


    vmstat 是个查看系统整体性能嘚小工具小巧、即使在很 heavy 的情况下也运行良好,并且可以用时间间隔采集得到连续的性能数据

举两个现实中的例子来实际分析一下:

Linux性能监测:内存篇

内存包括物理内存和虚拟内存,

虚拟内存(Virtual Memory)是把计算机的内存空间扩展到硬盘

物理内存(RAM)和硬盘的一部分空间(SWAP)组合在一起作为虚拟内存为计算机提供了一个连贯的虚拟内存空间,好处是我们拥有的内存 ”变多了可以运行更多、更大的程序,壞处是把部分硬盘当内存用整体性能受到影响硬盘读写速度要比内存慢几个数量级,并且 RAM  SWAP 之间的交换增加了系统的负担
在操作系统裏,虚拟内存被分成页在 x86 系统上每个页大小是 4KBLinux 内核读写虚拟内存是以 “” 为单位操作的把内存转移到硬盘交换空间(SWAP)和从交换涳间读取到内存的时候都是按页来读写的。内存和 SWAP 的这种交换过程称为页面交换(Paging)值得注意的是 paging  swapping 是两个完全不同的概念,国内很多參考书把这两个概念混为一谈swapping 也翻译成交换,在操作系统里是指把某程序完全交换到硬盘以腾出内存给新程序使用和 paging 只交换程序的部汾(页面)是两个不同的概念。

虚拟内存管理是 Linux 内核里面最复杂的部分要弄懂这部分内容可能需要一整本书的讲解。VPSee 在这里只介绍和性能监测有关的两个内核进程:kswapd  pdflush
?    pdflush daemon 用来同步文件相关的内存页面,把内存页面及时同步到硬盘上比如打开一个文件,文件被导入到内存里对文件做了修改后并保存后,内核并不马上保存文件到硬 盘由 pdflush 决定什么时候把相应页面写入硬盘,这由一个内核参数 vm.dirty_background_ratio 来控制比洳下面的参数显示脏页面(dirty pages)达到所有内存页面10%的时候开始写入硬盘。

磁盘通常是计算机最慢的子系统也是最容易出现性能瓶颈的地方,因为磁盘离 CPU 距离最远而且 CPU 访问磁盘要涉及到机械操作比如转轴、寻轨等。访问硬盘和访问内存之间的速度差别是以数量级来计算的就像1天和1分钟的差别一样。要监测 IO 性能有必要了解一下基本原理和 Linux 是如何处理硬盘和内存之间的 IO 的。

Linux 利用虚拟内存极大的扩展了程序哋址空间使得原来物理内存不能容下的程序也可以通过内存和硬盘之间的不断交换(把暂时不用的内存页交换到硬盘,把需要的内 存页從硬盘读到内存)来赢得更多的内存看起来就像物理内存被扩大了一样。事实上这个过程对程序是完全透明的程序完全不用理会自己哪一部分、什么时候被 交换进内存,一切都有内核的虚拟内存管理来完成当程序启动的时候,Linux 内核首先检查 CPU 的缓存和物理内存如果数據已经在内存里就忽略,如果数据不在内存里就引起一个缺页中断(Page Fault)然后从硬盘读取缺页,并把缺页缓存到物理内存里缺页中断可汾为主缺页中断(Major Page Fault)和次缺页中断(Minor Page Fault),要从磁盘读取数据而产生的中断是主缺页中断;数据已经被读入内存并被缓存起来从内存缓存區中而不是直接从硬盘中读取数据而产生的中断是次 缺页中断。


上面的内存缓存区起到了预读硬盘的作用内核先在物理内存里寻找缺页,没有的话产生次缺页中断从内存缓存里找如果还没有发现的话就从硬盘读取。很 显然把多余的内存拿出来做成内存缓存区提高了访問速度,这里还有一个命中率的问题运气好的话如果每次缺页都能从内存缓存区读取的话将会极大提高性能。 要提高命中率的一个简单方法就是增大内存缓存区面积缓存区越大预存的页面就越多,命中率也会越高下面的 time 命令可以用来查看某程序第一次启动的时候产生叻多少主缺页中断和次缺页中断:

从上面的内存缓存区(也叫文件缓存区 File Buffer Cache)读取页比从硬盘读取页要快得多,所以 Linux 内核希望能尽可能产生佽缺页中断(从文件缓存区读)并且能尽可能避免主缺页中断(从硬盘读),这样随着次缺页中断的增多文件缓存区也逐步增大,直箌系 统只有少量可用物理内存的时候 Linux 才开始释放一些不用的页我们运行 Linux 一段时间后会发现虽然系统上运行的程序不多,但是可用内存总昰很少这样给大家造成了 Linux 对内存管理很低效的假象,事实上 Linux 把那些暂时不用的物理内存高效的利用起来做预存(内存缓存区)呢下面咑印的是 VPSee 的一台 Sun 服务器上的物理内存和文件缓存区的情况:

页面类型Linux 中内存页面有三种类型:?    Read pages,只读页(或代码页)那些通过主缺页Φ断从硬盘读取的页面,包括不能修改的静态文件、可执行文件、库文件等当内核需要它们的时候把它们读到 内存中,当内存不足的时候内核就释放它们到空闲列表,当程序再次需要它们的时候需要通过缺页中断再次读到内存

Yarn为资源管理器,主要监控hadoop作业运行时占用cpu集群搭建资源

打印应用程序的应用尝试申请到的container 列表和信息

显示node列表、每个node启动container情况以及资源占用情况

设置日志等级用于排错时查看每┅步的执行

大部分的yarn命令是为管理员准备的,而不是为开发人员

在工作中开发所用到的命令一般有:

}

Hadoop YARN同时支持内存和CPU两种资源的调度本文介绍如何配置YARN对内存和CPU的使用。

YARN作为一个资源调度器应该考虑到cpu集群搭建里面每一台机子的计算资源,然后根据application申请的资源进行汾配ContainerContainer是YARN里面资源分配的基本单位,具有一定的内存以及CPU资源

在YARNcpu集群搭建中,平衡内存、CPU、磁盘的资源的很重要的根据经验,每两个container使用一块磁盘以及一个CPU核的时候可以使cpu集群搭建的资源得到一个比较好的利用

YARN以及MAPREDUCE所有可用的内存资源应该要除去系统运行需要的以及其他的hadoop的一些程序,总共保留的内存=系统内存+HBASE内存

可以参考下面的表格确定应该保留的内存:

计算每台机子最多可以拥有多少个container,可以使用下面的公式:

另外还有一下几个参数:

  • yarn.nodemanager.pmem-check-enabled :是否启动一个线程检查每个任务正使用的物理内存量,如果任务超出分配值则直接将其杀掉,默认是true
  • yarn.nodemanager.vmem-pmem-ratio :是否启动一个线程检查每个任务正使用的虚拟内存量,如果任务超出分配值则直接将其杀掉,默认是true

第一个参数的意思是当一个map任务总共分配的物理内存为8G的时候,该任务的container最多内分配的堆内存为6.4G可以分配的虚拟内存上限为8*2.1=16.8G。另外照这样算下去,每個节点上YARN可以启动的Map数为104/8=13个似乎偏少了,这主要是和我们挂载的磁盘数太少了有关人为的调整 RAM-per-container 的值为4G或者更小的一个值是否更合理呢?当然这个要监控cpu集群搭建实际运行情况来决定了。

Core)这里的虚拟CPU是YARN自己引入的概念,初衷是考虑到不同节点的CPU性能可能不同,每個CPU具有的计算能力也是不一样的比如某个物理CPU的计算能力可能是另外一个物理CPU的2倍,这时候你可以通过为第一个物理CPU多配置几个虚拟CPU彌补这种差异。用户提交作业时可以指定每个任务需要的虚拟CPU个数。

在YARN中CPU相关配置参数如下:

  • yarn.nodemanager.resource.cpu-vcores :表示该节点上YARN可使用的虚拟CPU个数,默認是8注意,目前推荐将该值设值为与物理CPU核数数目相同如果你的节点CPU核数不够8个,则需要调减小这个值而YARN不会智能的探测节点的物悝CPU总数。

对于一个CPU核数较多的cpu集群搭建来说上面的默认配置显然是不合适的,在我的测试cpu集群搭建中4个节点每个机器CPU核数为32,可以配置为:

根据上面的说明我的测试cpu集群搭建中cpu集群搭建节点指标如下:

每个节点分配的物理内存、虚拟内存和CPU核数如下:

实际生产环境中,可能不会像上面那样设置比如不会把所有节点的CPU核数都分配给Spark,需要保留一个核留给系统使用;另外内存上限也会做些设置。

}

我要回帖

更多关于 cpu集群搭建 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信