java实现:《操作系统实验三》模拟内存管理_对YARN资源管理的学习笔记

前言：

每次在网上查询hadoop的相关介绍，总会出现yarn。这些每次提到yarn都会说yarn负责计算资源的分配。作为一个分布式系统，计算资源是怎么表示的呢？yarn又是怎么管理这些资源？具体通过什么方式监控计算资源的使用情况呢？带着这些疑问，开始了这次学习，笔记如下：

转载：

yarn on yarn cgroup 资源隔离(cpu篇)

YARN 内存参数终极详解

CapacityScheduler源码分析之二——资源抢占

正文：

网上查了一些资料，有了一个简单的思路，后续阅读一些相关的书籍验证一下自己的思路是不是正确吧：

操作系统管理的资源，在我目前的世界观里有四个：[cpu/内存/磁盘io和空间/网络io]，查到的所有相关资料都只提到了cpu和内存，猜测与io相比，这两个更容易成为瓶颈，所以yarn对计算资源的配置项只有这两个。

具体理解yarn如何调度资源，根据查阅到的资料，感觉从下面三个方面描述比较容易理解：

<1>. 对于整个集群来说，具体每一个提交的资源能否立刻运行，如果不能，如何排队和调度。

<2>. 对于提交到集群上都一个job的某一个任务，具体会占用对应机器多少的内存资源。如何实现对内存资源的管理和控制。

<3>. 对于提交到集群上都一个job的某一个任务，具体会占用对应机器多少的cpu资源。如何实现对cpu资源的管理和控制。

ps:提交一个mapreduce任务的时候，与资源相关的配置项有下边几个，正好跟上边三点相对应：

mapreduce.map.cpu.vcores 与cpu相关的配置

mapreduce.map.memory.mb 和 mapreduce.map.java.opts 与内存相关的配置

mapreduce.job.queuename 和 mapreduce.job.priority 与队列调度相关的配置项

下面就分别简单描述一下：

• 一、cpu

参考yarn on yarn cgroup 资源隔离(cpu篇)这片篇文章。

yarn-default.xml中的yarn.nodemanager.container-executor.class 决定是否开启cpu资源隔离策略，参考YARN源码解析(7)-NodeManager中几种ContainerExecutor,如果配置为LinuxContainerExecutor yarn就会使用cgroups对cpu资源进行隔离。

cgroups对资源的隔离又分两种，通过配置项yarn.nodemanager.linux-container-executor.cgroups.strict-resource-usage的值来决定。如果为true，则通过时间片占比严格控制cpu使用率，如果为false，则通过任务权重，根据正在执行的任务动态的调整cpu使用率。

之前一直不太理解，为什么机器的cpu资源要用核数来定义。比如如果两台物理机器A和B，如果说两台机器都是16g内存，那么可以确定两者的内存是一样大的，但是如果说两个机器都有4个核，并不能确定两台机器的计算能力是否一致。比如一台使用i7处理器，一台使用i5处理器。

对于一个分布式系统来说，集群中机器的运算能力有可能是不一样的。为了能够统一的管理计算资源，yarn中的每个nodemanager的core数量并不是物理core的数量，而是可以通过配置文件yarn-default.xml的yarn.nodemanager.resource.cpu-vcores 来设置的，后续提交的任务的mapreduce.map.cpu.vcores也是基于这个配置的值来计算具体使用的cpu资源数量。所以这个core是个抽象的概念，跟操作系统监控中的core不是一个东西。

• 二、内存

参考YARN 内存参数终极详解这片篇文章。

这个部分是最蛋疼的部分，yarn并没有使用cgroups来管理内存，而是暴力的通过设置一个任务的最大内存的方式来管理，如果一个任务使用的内存超过了设定值，直接杀死任务然后报错。所以理解这个问题的关键是明白一个任务的内存限制是多大。

接下来就是蛋疼的地方了，总共找到了三个参数与这个相关：

<1>. mapreduce.map.memory.mb map任务可以占用机器的最大物理内存量。

<2>. mapreduce.map.java.opts 中的 -Xms -Xmx map任务启动的jvm虚拟机最大内存设置。

<3>. yarn.nodemanager.vmem-pmem-ratio 任务占用的虚拟内存上限与物理内存上限的比值。

三个参数提到了三个内存概念，物理内存、虚拟内存、jvm内存。瞬间就蒙圈了，看了YARN 内存参数终极详解这片篇文章之后，才知道top命令中，一个进程占用的内存有物理内存和虚拟内存两个。那么一个jvm进程占用的虚拟内存多大呢？跟jvm的参数有关系吗？

最开始猜测jvm设置的最大内存就是虚拟内存，于是就在本地启动了一个jvm虚拟机，设置启动参数-Xms500m -Xmx500m 然后top发现不是这么回事。

//A.java
public class A
{
    public static final byte [][][] ARRAY= new byte[1024][1024][100];
    public static void main(String[] args) {
        try{
            Thread.sleep(10000000);
        }catch (Exception e){
            e.printStackTrace();
        }
    }
}

执行结果：

上图可以看见，jvm进程占用了2g多的虚拟内存，于是查了一些资料，找到了这个帖子：Linux上java进程虚拟内存VIRT占用高的问题 暂时没有看懂，为了简化问题难度，就按照帖子上说的，暂时忽略虚拟内存大小的限制。

剩下的就是物理内存和jvm堆内存大小限制的关系了。container物理内存限制指的是，container进程以及其生成的子进程占用的物理内存的总和。问题是jvm是一个用户进程，用户进程只能看见自己的虚拟内存，只有操作系统才能决定具体用户进程的虚拟内存，有多少在物理内存里，有多少在swap区。
所以我的理解是，完全可以设置mapreduce.map.memory.mb=1g，然后jvm启动参数设置-Xms2048m -Xmx2048m.因为决定是否杀死进程的是进程占用的物理内存总和，有可能jstat显示jvm使用了2g内存，但是实际上，大部分都在swap区，真正占用的物理内存大小 小于1g。（只是猜测，后续补上测试结果）

如果真是这样的话，之前对内存监控的理解是有问题的，线上服务除了要看jvm的内存监控以外，还要看机器的物理内存监控。

• 三、任务调度策略

写到这里的时候，已经开始犯困了。。。而且这个部分看的时候也没有发现什么有意思的东西，暂时不写了，参照CapacityScheduler源码分析之二——资源抢占这篇文章吧。

总结：

这篇笔记留了一个小坑，后续做完实验补上。大数据的各种个样的技术琳琅满目，争奇斗艳，感觉自己跳进了一个大坑，有点目不暇接，不知所措。总之千里之行始于足下，希望能够一点一点的画出自己的大数据地图，明白自己身在何处，能去何方吧。

最后，让我们保持独立思考，不卑不亢。长成自己想要的样子！ (引用自 我非常喜欢的B站up主 ”独立菌儿“->猛戳链接<-的口头禅）