过去，一直习惯于在 Yarn 的 ResourceManager 页面上，通过菜单：Cluster -> Scheduler 查看当前 Yarn 总体的资源分配状况，因为这个页面非常直观。不过，在最近一次测试中，我发现：Yarn ResourceManager 页面上的绿色条块（Used Resources）并不能如实地反映集群当前实际的资源占用情况，这一点需要注意，并且要改正一下过去养成的这一习惯了！下面是此次发现问题的案例（测试使用的是 AWS EMR 5.23，这个问题也可能和 Hadoop 版本有关，末在其他版本上测试，请注意版本问题！）：
测试集群有 20 个 Worker 节点，每个节点是 16 vCore, 64 G 内存，通过配置，每个 NodeManager 获得了 60 G 内存，在一次测试中，提交了一个 Map-Reduce 作业，Map-Reduce 和 Yarn 的关键配置如下：
{
"Classification": "yarn-site",
"Properties": {
"yarn.nodemanager.resource.memory-mb": "61440",
"yarn.scheduler.maximum-allocation-mb": "61440",
"yarn.nodemanager.vmem-pmem-ratio": "10"
}
},
{
"Classification": "mapred-site",
"Properties": {
"mapreduce.map.memory.mb": "13440",
"mapreduce.map.java.opts": "-Xmx10752m",
"mapreduce.map.cpu.vcores": "16",
"mapreduce.reduce.memory.mb": "7680",
"mapreduce.reduce.java.opts": "-Xmx6144m",
"mapreduce.reduce.cpu.vcores": "16",
"yarn.app.mapreduce.am.resource.mb": "7680",
"yarn.app.mapreduce.am.resource.cpu-vcores": "16"
}
}
在作业启动时，申请的 Container 数量是：90 个 Mapper！注意：这里的 90 个 Mapper 是按：( 61440 * 20 - 7680 ) / 13440 = 90.86，然后向下取整得到的，显然，这一算法是错误的，因为总的内存资源不是连在一起的，物理上被分隔成了20份（20个节点），只能按节点计算出每个节点可以分配的容器数，然后乘以20才对。所以：以 13440 MB 切分容器的话，每个节点只能切分出：4 个整的容器，剩余 0.57 个容器是不能被分配出来的，所以，整个集群其实最多只能切分出 80个 Map Container。
下面，我们看一下作业提交后，Yarn ResourceManager 页面上的实际信息：
你会看到：绿色条块是按 90 个 mapper 的规划计算的，总内存是：(1344090+7680)/(6144020) = 99.065 % = 99.1%，这就是页面上 99.1 % 的来历。但是，正如上面所分析的，实际应用获得的 map 容器只有 80 个，准确的值其实是在下面的 application 信息中给出的。
不过，如果我们点到作业里去看，这个作业总共规划的确实是 90 个 mapper，有10 个会处于 pending 状态，等现行执行的map 任务结束后，空余出container来，会继续执行剩余的10个。不过，无论如何，页面上显式99.1% 的资源占用是不对的！这会误导开发者。所以，以后还是要以下方 application 输出的信息为准！
