目录

1. 梳理YARN资源调优参数
2. 调度器整理三种，区别是什么，CDH默认是什么

YARN的资源调优

背景: 假设每台服务器拥有内存128G 16物理core，怎么分配？

1. 装完CentOS，消耗内存1G

2. 系统预览15%-20%内存(包含1.1)，以防全部使用导致系统夯住 和 oom机制事件，或者给未来部署组件预览点空间(128*20%=25.6G==26G)

3. 假设只有DN NM节点，余下内存: 128-26=102G

   1. 给DN进程(自身)2G，给NM进程(自身)4G，剩余102-2-4=96G

   2. container内存的分配共96G

      • yarn.nodemanager.resource.memory-mb 共 96G

      • yarn.scheduler.minimum-allocation-mb 最少1G 极限情况下，只有96个container 内存1G

      • yarn.scheduler.maximum-allocation-mb 最多96G 极限情况下，只有1个container 内存96G

        container的内存会自动增加，默认1G递增，那么container的个数的范围: 1-96个

   3. container物理核分配 (物理核:虚拟核 =1:2 ==>16:32)

      • yarn.nodemanager.resource.cpu-vcores 共 32个

      • yarn.scheduler.minimum-allocation-vcores 最少1个 极限情况下，只有32个container

      • yarn.scheduler.maximum-allocation-vcores 最多32个 极限情况下，只有1个container

        container的物理核会自动增加，默认1个递增，那么container的个数的范围: :1-32个

   4. 关键: cloudera公司推荐，一个container的vcore最好不要超过5，那么我们设置4

      • yarn.scheduler.maximum-allocation-vcores 4

        目前为止，极限情况下，共有8个container (32/4)

   5. 综合memory+vcore的分配

      1. 一共有32个vcore，一个container的vcore是4个，那么分配container一共有8个

      2. 重新分配核

         • yarn.nodemanager.resource.cpu-vcores 共32个

         • yarn.scheduler.minimum-allocation-vcores 最少4个

         • yarn.scheduler.maximum-allocation-vcores 最多4个 极限container 8个

      3. 根据物理核重新分配内存

         • yarn.nodemanager.resource.memory-mb 共96G

         • yarn.scheduler.minimum-allocation-mb 最少12G

         • yarn.scheduler.maximum-allocation-mb 最多12G (极限container 8个)

      4. 分配后的每个container的物理核数是4个，内存大小是12G，当然spark计算时内存不够大，这个参数肯定要调大，那么这种理想化的设置个数必然要打破，以memory为主

   6. 假如 256G内存 56core，请问参数如何设置

      1. 首先减去系统内存开销和其他进程开销，

         • 系统开销: 256*0.2=52G

         • DN开销: 2G

         • NM开销: 4G

         • Hbase开销: 暂无

         • 升序内存容量: 256-52-2-4=198G

      2. 确定每个container的物理核数量是4个，56/4=14个container容器

      3. 确定了最多分配14个container容器，每个容器的内存应该分配的容量是: 198/14==>14G

         那么每个container的最大核数设置4，最大内存数设置14G

   7. 假如该节点还有组件，比如hbase regionserver进程，那么该如何设置？

      总容量减就完事了。

   所有的配置信息在yarn-default.xml文件中

   内存参数默认值:

   KEY	VALUE	DESC
   yarn.nodemanager.resource.memory-mb	-1	可以分配给容器的物理内存总量(以MB为单位)。
   yarn.scheduler.minimum-allocation-mb	1024	RM上每个容器请求的最小分配
   yarn.scheduler.maximum-allocation-mb	8192	RM上每个容器请求的最大分配

   核数参数默认值:

   KEY	VALUE	DESC
   yarn.nodemanager.resource.cpu-vcores	-1	可以为容器分配的vcore总数量。
   yarn.scheduler.minimum-allocation-vcores	1	RM上每个容器请求的最小虚拟CPU核心分配。
   yarn.scheduler.maximum-allocation-vcores	4	RM上每个容器请求的最大虚拟CPU核心分配。

Yarn的三种调度器

• Apache hadoop2.x的默认调度器是Capacity Scheduler(计算调度器)

• CDH的默认调度器是Fair Scheduler(公平调度器)

Yarn三种调度策略对比

在Yarn中有三种调度器可以选择：FIFO Scheduler ，Capacity Scheduler，FairScheduler。

1. FIFO Scheduler

   

   FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。

   FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。从图中可以看出，在FIFO 调度器中，小任务会被大任务阻塞。

2. Capacity Scheduler

   

   而对于Capacity调度器，有一个专门的队列用来运行小任务，但是为小任务专门设置一个队列会预先占用一定的集群资源，这就导致大任务的执行时间会落后于使用FIFO调度器时的时间。

3. Fair Scheduler

   

   在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如上图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。

   需要注意的是，在上图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。

常用命令

yarn application -kill <Application ID>	#杀死进程