欢迎光临
让我们一起努力

hadoop之yarn(优化篇)

最近一直在学习hadoop的一些原理和优化,然后也做了一些实践,也有没有去做实践的,反正个人观点都记录下来

一、yarn的介绍

  YARN的基本结构由一个ResourceManager与多个NodeManager组成。ResourceManager负责对NodeManager所持有的资源进行统一管理和调度。当在处理一个作业时ResourceManager会在NodeManager所在节点创建一全权负责单个作业运行和监控的程序ApplicationMaster。

1、ResouceManager(简称RM)

  资源管理器负责整个集群资源的调度,该组件由两部分构成:调度器(Scheduler)和ApplicationsManager。调度器会根据特定调度器实现调度算法,结合作业所在的队列资源容量,将资源按调度算法分配给每个任务。分配的资源将用容器(container)形式提供,容器是一个相对封闭独立的环境,已经将CPU、内存及任务运行所需环境条件封装在一起。通过容器可以很好地限定每个任务使用的资源量。YARN调度器目前在生产环境中被用得较多的有两种:能力调度器(Capacity Scheduler)和公平调度器(Fair Scheduler)(FIFO一般都不使用)。

2、ApplicationMaster(简称AM)

  每个提交到集群的作业(job)都会有一个与之对应的AM 来管理。它负责进行数据切分,并为当前应用程序向RM 去申请资源,当申请到资源时会和NodeManager 通信,启动容器并运行相应的任务。此外,AM还负责监控任务(task)的状态和执行的进度。

3、NodeManage(简称NM)

  NodeManager负责管理集群中单个节点的资源和任务,每个节点对应一个NodeManager, NodeManager负责接收ApplicationMaster的请求启动容器,监控容器的运行状态,并监控当前节点状态及当前节点的资源使用情况和容器的运行情况,并定时回报给ResourceManager

更具体点的知识可以参考hadoop之yarn详解(基础架构篇)hadoop之yarn详解(框架进阶篇)hadoop之yarn详解(命令篇)这几篇文章

二、yarn的优化

丢个官网:https://hadoop.apache.org/docs/stable/hadoop-yarn/hadoop-yarn-common/yarn-default.xml

  这里不说调度器的配置,一般都是选用能力调度器(Capacity Scheduler)和公平调度器(Fair Scheduler),这些一般都是根据公司的具体情况进行配置,比如根据用户配置资源比例,或者更具时间点的不同配置,毕竟有时候离线计算在某些时候压力会比较大,可以根据公司的具体情况,对具体的一些时间段进行相应的调整,防止集群压力过大,造成集群不健康。

2.1、资源配置

  在YARN中可供分配和管理的资源有内存和CPU资源,在Hadoop 3.0中将GPU、FPGA资源也纳入可管理的资源中。

  既然yarn是用来管理资源的,所以资源的来源还是来源于服务器的cpu和内存。所以也就是我们配置服务器的多少资源作为yarn的资源。这里有两种配置,一种是自己更具服务器的资源,自己判断预留给服务器多少资源提供给其他服务,其他配置给yarn作为资源,还有一种就是让yarn去扫描服务器的资源,按照比例进行配置(这个理论上可行,没有实践)

  这里再说一句,优化这个东西呢其他在集群没有出现瓶颈的时候就不要去优化,一个是看不出效果,还有就是浪费时间,反正资源够用,没啥好优化的,优化的目的就是在有限的资源下,保证集群的稳定,又能挺高资源的利用率和提高集群的并发能力。

首先我们说第一种:手动配置固定的资源给yarn

yarn.nodemanager.resource.cpu-vcores,默认值为-1。默认表示集群中每个节点可被分配的虚拟CPU个数为8。为什么这里不是物理CPU个数?因为考虑一个集群中所有的机器配置不可能一样,即使同样是16核心的CPU性能也会有所差异,所以YARN在物理CPU和用户之间加了一层虚拟CPU,一个物理CPU可以被划分成多个虚拟的CPU。这里确实可以配置超过物理cpu的个数,确实能够提高并发,但是尝试了一把,这样子服务器的负载就很大了,基本上是处理不过来,而且这样配置没有个服务器留有空余的cpu去执行其他的任务或者其他的集群。因为是生产环境,也没敢去做压测,检测到服务器的负载都是cpu核数的十倍了,所以负载太大,不太敢太激进,所以最终配置是比物理cup核数少那么几个,预留几个cpu给服务器或者其他服务使用。

 yarn.nodemanager.resource.memory-mb,默认值为-1。当该值为-1时,默认表示集群中每个节点可被分配的物理内存是8GB。这个一般配置是给服务器预留20%的内存即可。

 

接下来说说第二种:让yarn自动探测服务器的资源,然后预留一定比例给服务器,然后就可以把vcore调的大一些,这样既能提高cpu的使用率,有能保证给服务器留有一定的cpu

首先yarn.nodemanager.resource.cpu-vcores和yarn.nodemanager.resource.memory-mb都要采用默认值-1,这样如下的配置才会生效:

yarn.nodemanager.resource.detect-hardware-capabilities 配置为true,表示可以让yarn自动探测服务器的资源,比如cpu和内存等

然后我们就配置可以留给服务器的内存和可以使用物理cpu的比例:

yarn.nodemanager.resource.system-reserved-memory-mb:YARN保留的物理内存,给非YARN任务使用,该值一般不生效,只有当yarn.nodemanager.resource.detect-hardware-capabilities为true的状态才会启用,会根据系统的情况自动计算

yarn.nodemanager.resource.percentage-physical-cpu-limit:默认是100,表示100%使用,这里我们比如可以配置80%,表示预留给服务器或者其他应用20%的cpu

yarn.nodemanager.resource.pcores-vcores-multiplier:默认为1,表示一个物理cpu当做一个vcore使用,如果我们已经预留给了服务器cpu的话,那我们这里可以调整问题2或者3,这样一个物理cpu可以当做2个或者3个vcore使用,毕竟每个map和reduce作业都要配置cpu,但是有些map和reduce作业又不是计算型作业,所以这样就可以更合理的利用资源。类似把蛋糕切小块,少需的拿一块,多需求的多拿几块,这样提高了cpu的利用率和提高了集群的并发能力。(这么配置的前提是集群的瓶颈在于cpu不够使用)

yarn.nodemanager.vmem-pmem-ratio,默认值为2.1。该值为可使用的虚拟内存除以物理内存,即YARN 中任务的单位物理内存相对应可使用的虚拟内存。例如,任务每分配1MB的物理内存,虚拟内存最大可使用2.1MB,如果集群缺内存,可以增大该值。

注意:如果集群的资源很充足,就不要把一个物理cpu当2个或者3个使用,也不要吧虚拟内存比例调大,资源够用就是不用优化,优化只是在资源不够的情况进行的。

如上我们配置yarn集群的资源,cpu和内存,但是在作业的执行的过中是以container为单位的,现在我们来配置container的资源。

yarn.scheduler.minimum-allocation-mb:默认值1024MB,是每个容器请求被分配的最小内存。如果容器请求的内存资源小于该值,会以1024MB 进行分配;如果NodeManager可被分配的内存小于该值,则该NodeManager将会被ResouceManager给关闭。

yarn.scheduler.maximum-allocation-mb:默认值8096MB,是每个容器请求被分配的最大内存。如果容器请求的资源超过该值,程序会抛出InvalidResourceRequest Exception的异常。

yarn.scheduler.minimum-allocation-vcores:默认值1,是每个容器请求被分配的最少虚拟CPU 个数,低于此值的请求将被设置为此属性的值。此外,配置为虚拟内核少于此值的NodeManager将被ResouceManager关闭。

yarn.scheduler.maximum-allocation-vcores:默认值4,是每个容器请求被分配的最少虚拟CPU个数,高于此值的请求将抛出InvalidResourceRequestException的异常。如果开发者所提交的作业需要处理的数据量较大,需要关注上面配置项的配置

2.2、线程配置

资源配置固然重要,但是影响yarn性能的不单单只是资源,还有各个组件之间的配合,线程的数量直接影响到并发的能力,当然也不能配置的太高,这样会给集群造成不小的压力,所以要根据自己集群的状态进行合理的配置。

yarn.resourcemanager.client.thread-count:默认50,用于处理应用程序管理器请求的线程数

yarn.resourcemanager.amlauncher.thread-count:默认50,用于启动/清理AM的线程数

yarn.resourcemanager.scheduler.client.thread-count:默认50,处理来自ApplicationMaster的RPC请求的Handler数目,比较重要

yarn.resourcemanager.resource-tracker.client.thread-count:默认50,处理来自NodeManager的RPC请求的Handler数目,比较重要

yarn.resourcemanager.admin.client.thread-count:默认1,用于处理RM管理接口的线程数。

yarn.nodemanager.container-manager.thread-count:默认20,container 管理器使用的线程数。

yarn.nodemanager.collector-service.thread-count:默认5,收集器服务使用的线程数

yarn.nodemanager.delete.thread-count:默认4,清理使用的线程数。

yarn.nodemanager.localizer.client.thread-count:默认5,处理本地化请求的线程数。

yarn.nodemanager.localizer.fetch.thread-count:默认4,用于本地化获取的线程数

yarn.nodemanager.log.deletion-threads-count:默认4,在NM日志清理中使用的线程数。在禁用日志聚合时使用

yarn.timeline-service.handler-thread-count:用于服务客户端RPC请求的处理程序线程计数。

2.3、log日志和文件目录配置

yarn.nodemanager.log-dirs:日志存放地址(建议配置多个目录),默认值:${yarn.log.dir}/userlogs

yarn.nodemanager.local-dirs:中间结果存放位置,建议配置多个目录,分摊磁盘IO负载,默认值:${hadoop.tmp.dir}/nm-local-dir

yarn.log-aggregation-enable:默认false,是否启用日志聚合

yarn.log-aggregation.retain-seconds:聚合日志的保留时长,设置到3-7天即可,默认-1

yarn.nodemanager.remote-app-log-dir:默认/tmp/logs,本地聚合在hdfs上的日志目录

yarn.nodemanager.remote-app-log-dir-suffix:{yarn.nodemanager.remote-app-log-dir}/${user}/{thisParam}用于存放聚合后的日志

yarn.nodemanager.recovery.dir:默认${hadoop.tmp.dir}/yarn-nm-recovery,本地文件系统目录,当启用恢复时,nodemanager将在其中存储状态。只有当yarn.nodemanager.recovery.enabled为true的情况下才有用,该值默认false

yarn.resourcemanager.recovery.enabled:默认fasle,当RM启用高可用的时候默认启用,但是必须配置yarn.resourcemanager.store.class,该值默认为org.apache.hadoop.yarn.server.resourcemanager.recovery.FileSystemRMStateStore,最好配置配org.apache.hadoop.yarn.server.resourcemanager.recovery.ZKRMStateStore

赞(0) 我这么幸苦,不打个赏再走?
本作品采用CC BY-NC-SA 4.0进行许可:小李子的blog » hadoop之yarn(优化篇)

评论 抢沙发

CAPTCHAis initialing...
  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

微信扫一扫打赏