YARN的内存和CPU配置
YARN的内存和CPU配置
Hadoop YARN同时支持内存和CPU两种资源的调度，本文介绍如何配置YARN对内存和CPU的使用。
YARN作为一个资源调度器，应该考虑到集群里面每一台机子的计算资源，然后根据application申请的资源进行分配Container。
Hadoop YARN同时支持内存和CPU两种资源的调度，本文介绍如何配置YARN对内存和CPU的使用。
YARN作为一个资源调度器，应该考虑到集群里面每一台机子的计算资源，然后根据application申请的资源进行分配Container。Container是YARN里面资源分配的基本单位，具有一定的内存以及CPU资源。
在YARN集群中，平衡内存、CPU、磁盘的资源的很重要的，根据经验，每两个container使用一块磁盘以及一个CPU核的时候可以使集群的资源得到一个比较好的利用。
关于内存相关的配置可以参考hortonwork公司的文档来配置你的集群。
YARN以及MAPREDUCE所有可用的内存资源应该要除去系统运行需要的以及其他的hadoop的一些程序，总共保留的内存=系统内存+HBASE内存。
可以参考下面的表格确定应该保留的内存：
每台机子内存
系统需要的内存
HBase需要的内存
计算每台机子最多可以拥有多少个container，可以使用下面的公式:
containers = min (2*CORES, 1.8*DISKS, (Total available RAM) / MIN_CONTAINER_SIZE)
CORES为机器CPU核数
DISKS为机器上挂载的磁盘个数
Total available RAM为机器总内存
MIN_CONTAINER_SIZE是指container最小的容量大小，这需要根据具体情况去设置，可以参考下面的表格：
每台机子可用的RAM
container最小值
4GB到8GB之间
8GB到24GB之间
每个container的平均使用内存大小计算方式为：
RAM-per-container = max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))
通过上面的计算，YARN以及MAPREDUCE可以这样配置：
yarn-site.xml
yarn.nodemanager.resource.memory-mb
= containers * RAM-per-container
yarn-site.xml
yarn.scheduler.minimum-allocation-mb
= RAM-per-container
yarn-site.xml
yarn.scheduler.maximum-allocation-mb
= containers * RAM-per-container
yarn-site.xml (check)
yarn.app.mapreduce.am.resource.mb
= 2 * RAM-per-container
yarn-site.xml (check)
yarn.app.mapreduce.am.command-opts
= 0.8 * 2 * RAM-per-container
mapred-site.xml
mapreduce.map.memory.mb
= RAM-per-container
mapred-site.xml
mapreduce.reduce.memory.mb
= 2 * RAM-per-container
mapred-site.xml
mapreduce.map.java.opts
= 0.8 * RAM-per-container
mapred-site.xml
mapreduce.reduce.java.opts
= 0.8 * 2 * RAM-per-container
举个例子：对于128G内存、32核CPU的机器，挂载了7个磁盘，根据上面的说明，系统保留内存为24G，不适应HBase情况下，系统剩余可用内存为104G，计算containers值如下：
containers = min (2*32, 1.8* 7 , (128-24)/2) = min (64, 12.6 , 51) = 13
计算RAM-per-container值如下：
RAM-per-container = max (2, (124-24)/13) = max (2, 8) = 8
你也可以使用脚本来计算上面的值：
#!/usr/bin/env python
import optparse
from pprint import pprint
import logging
import sys
import math
import ast
''' Reserved for OS + DN + NM,
Map: Memory =& Reservation '''
reservedStack = { 4:1, 8:2, 16:2, 24:4, 48:6, 64:8, 72:8, 96:12,
128:24, 256:32, 512:64}
''' Reserved for HBase. Map: Memory =& Reservation '''
reservedHBase = {4:1, 8:1, 16:2, 24:4, 48:8, 64:8, 72:8, 96:16,
128:24, 256:32, 512:64}
def getMinContainerSize(memory):
if (memory &= 4):
return 256
elif (memory &= 8):
return 512
elif (memory &= 24):
return 1024
return 2048
def getReservedStackMemory(memory):
if (reservedStack.has_key(memory)):
return reservedStack[memory]
if (memory &= 4):
elif (memory &= 512):
return ret
def getReservedHBaseMem(memory):
if (reservedHBase.has_key(memory)):
return reservedHBase[memory]
if (memory &= 4):
elif (memory &= 512):
return ret
def main():
log = logging.getLogger(__name__)
out_hdlr = logging.StreamHandler(sys.stdout)
out_hdlr.setFormatter(logging.Formatter(' %(message)s'))
out_hdlr.setLevel(logging.INFO)
log.addHandler(out_hdlr)
log.setLevel(logging.INFO)
parser = optparse.OptionParser()
memory = 0
hbaseEnabled = True
parser.add_option('-c', '--cores', default = 16,
help = 'Number of cores on each host')
parser.add_option('-m', '--memory', default = 64,
help = 'Amount of Memory on each host in GB')
parser.add_option('-d', '--disks', default = 4,
help = 'Number of disks on each host')
parser.add_option('-k', '--hbase', default = "True",
help = 'True if HBase is installed, False is not')
(options, args) = parser.parse_args()
cores = int (options.cores)
memory = int (options.memory)
disks = int (options.disks)
hbaseEnabled = ast.literal_eval(options.hbase)
log.info("Using cores=" +
str(cores) + " memory=" + str(memory) + "GB" +
" disks=" + str(disks) + " hbase=" + str(hbaseEnabled))
minContainerSize = getMinContainerSize(memory)
reservedStackMemory = getReservedStackMemory(memory)
reservedHBaseMemory = 0
if (hbaseEnabled):
reservedHBaseMemory = getReservedHBaseMem(memory)
reservedMem = reservedStackMemory + reservedHBaseMemory
usableMem = memory - reservedMem
memory -= (reservedMem)
if (memory & 2):
memory = 2
reservedMem = max(0, memory - reservedMem)
memory *= GB
containers = int (min(2 * cores,
min(math.ceil(1.8 * float(disks)),
memory/minContainerSize)))
if (containers &= 2):
containers = 3
log.info("Profile: cores=" + str(cores) + " memory=" + str(memory) + "MB"
+ " reserved=" + str(reservedMem) + "GB" + " usableMem="
+ str(usableMem) + "GB" + " disks=" + str(disks))
container_ram =
abs(memory/containers)
if (container_ram & GB):
container_ram = int(math.floor(container_ram / 512)) * 512
log.info("Num Container=" + str(containers))
log.info("Container Ram=" + str(container_ram) + "MB")
log.info("Used Ram=" + str(int (containers*container_ram/float(GB))) + "GB")
log.info("Unused Ram=" + str(reservedMem) + "GB")
log.info("yarn.scheduler.minimum-allocation-mb=" + str(container_ram))
log.info("yarn.scheduler.maximum-allocation-mb=" + str(containers*container_ram))
log.info("yarn.nodemanager.resource.memory-mb=" + str(containers*container_ram))
map_memory = container_ram
reduce_memory = 2*container_ram if (container_ram &= 2048) else container_ram
am_memory = max(map_memory, reduce_memory)
log.info("mapreduce.map.memory.mb=" + str(map_memory))
log.info("mapreduce.map.java.opts=-Xmx" + str(int(0.8 * map_memory)) +"m")
log.info("mapreduce.reduce.memory.mb=" + str(reduce_memory))
log.info("mapreduce.reduce.java.opts=-Xmx" + str(int(0.8 * reduce_memory)) + "m")
log.info("yarn.app.mapreduce.am.resource.mb=" + str(am_memory))
log.info("yarn.app.mapreduce.am.command-opts=-Xmx" + str(int(0.8*am_memory)) + "m")
log.info("mapreduce.task.io.sort.mb=" + str(int(0.4 * map_memory)))
if __name__ == '__main__':
except(KeyboardInterrupt, EOFError):
print("\nAborting ... Keyboard Interrupt.")
sys.exit(1)
执行下面命令：
python yarn-utils.py -c 32 -m 128 -d 7 -k False
返回结果如下：
Using cores=32 memory=128GB disks=7 hbase=False
Profile: cores=32 memory=106496MB reserved=24GB usableMem=104GB disks=7
Num Container=13
Container Ram=8192MB
Used Ram=104GB
Unused Ram=24GB
yarn.scheduler.minimum-allocation-mb=8192
yarn.scheduler.maximum-allocation-mb=106496
yarn.nodemanager.resource.memory-mb=106496
mapreduce.map.memory.mb=8192
mapreduce.map.java.opts=-Xmx6553m
mapreduce.reduce.memory.mb=8192
mapreduce.reduce.java.opts=-Xmx6553m
yarn.app.mapreduce.am.resource.mb=8192
yarn.app.mapreduce.am.command-opts=-Xmx6553m
mapreduce.task.io.sort.mb=3276
这样的话，每个container内存为8G，似乎有点多，我更愿意根据集群使用情况任务将其调整为2G内存，则集群中下面的参数配置值如下：
yarn-site.xml
yarn.nodemanager.resource.memory-mb
= 52 * 2 =104 G
yarn-site.xml
yarn.scheduler.minimum-allocation-mb
yarn-site.xml
yarn.scheduler.maximum-allocation-mb
= 52 * 2 = 104G
yarn-site.xml (check)
yarn.app.mapreduce.am.resource.mb
= 2 * 2=4G
yarn-site.xml (check)
yarn.app.mapreduce.am.command-opts
= 0.8 * 2 * 2=3.2G
mapred-site.xml
mapreduce.map.memory.mb
mapred-site.xml
mapreduce.reduce.memory.mb
= 2 * 2=4G
mapred-site.xml
mapreduce.map.java.opts
= 0.8 * 2=1.6G
mapred-site.xml
mapreduce.reduce.java.opts
= 0.8 * 2 * 2=3.2G
对应的xml配置为：
&property&
&name&yarn.nodemanager.resource.memory-mb&/name&
&value&106496&/value&
&/property&
&property&
&name&yarn.scheduler.minimum-allocation-mb&/name&
&value&2048&/value&
&/property&
&property&
&name&yarn.scheduler.maximum-allocation-mb&/name&
&value&106496&/value&
&/property&
&property&
&name&yarn.app.mapreduce.am.resource.mb&/name&
&value&4096&/value&
&/property&
&property&
&name&yarn.app.mapreduce.am.command-opts&/name&
&value&-Xmx3276m&/value&
&/property&
另外，还有一下几个参数：
yarn.nodemanager.vmem-pmem-ratio：任务每使用1MB物理内存，最多可使用虚拟内存量，默认是2.1。
yarn.nodemanager.pmem-check-enabled：是否启动一个线程检查每个任务正使用的物理内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
yarn.nodemanager.vmem-pmem-ratio：是否启动一个线程检查每个任务正使用的虚拟内存量，如果任务超出分配值，则直接将其杀掉，默认是true。
第一个参数的意思是当一个map任务总共分配的物理内存为2G的时候，该任务的container最多内分配的堆内存为1.6G，可以分配的虚拟内存上限为2*2.1=4.2G。另外，照这样算下去，每个节点上YARN可以启动的Map数为104/2=52个。
YARN中目前的CPU被划分成虚拟CPU（CPU virtual 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总数。
yarn.scheduler.minimum-allocation-vcores：单个任务可申请的最小虚拟CPU个数，默认是1，如果一个任务申请的CPU个数少于该数，则该对应的值改为这个数。
yarn.scheduler.maximum-allocation-vcores：单个任务可申请的最多虚拟CPU个数，默认是32。
对于一个CPU核数较多的集群来说，上面的默认配置显然是不合适的，在我的测试集群中，4个节点每个机器CPU核数为31，留一个给操作系统，可以配置为：
&property&
&name&yarn.nodemanager.resource.cpu-vcores&/name&
&value&31&/value&
&/property&
&property&
&name&yarn.scheduler.maximum-allocation-vcores&/name&
&value&124&/value&
&/property&
用云栖社区APP，舒服~
【云栖快讯】新手小白必看！编程语言系列讲座火爆进行中，与行业资深专家一起学习Python、C++、JavaScript、Java！从入门到进阶&&
用配置管理（Application Configuration Management，简称 ...
一种高性能、高可靠、可平滑扩容的分布式内存数据库服务。
是一种简单易用的云计算资源管理和自动化运维服务。用户通过模板描述多个云计算资源的依赖关系、配...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效...
阿里云飞天战略营全新发布查看: 23752|回复: 12
Yarn简单介绍及内存配置
主题帖子积分
中级会员, 积分 771, 距离下一级还需 229 积分
中级会员, 积分 771, 距离下一级还需 229 积分
本帖最后由 徐超 于
13:07 编辑
1、Yarn对MRv1的改进有哪些？
2、怎样对Yarn简单的内存配置？
3、如何理解Yarn的资源抽象container？
在这篇中，主要介绍了Yarn对MRv1的改进，以及Yarn简单的内存配置和Yarn的资源抽象container。
我么知道MRv1存在的主要问题是：在运行时，JobTracker既负责资源管理又负责任务调度，这导致了它的扩展性、资源利用率低等问题。之所以存在这样的问题，是与其最初的设计有关，如下图：
1.png (20.07 KB, 下载次数: 17)
12:39 上传
从上图可以看到，MRv1是围绕着MapReduce进行，并没有过多地考虑以后出现的其它数据处理方式 。按着上图的设计思路，我们每开发一种数据处理方式（例如spark），都要重复实现相应的集群资源管理和数据处理。因此，Yarn就很自然的被开发出来了。
Yarn对MRv1的最大改进就是将资源管理与任务调度分离，使得各种数据处理方式能够共享资源管理，如下图所示：
2.png (28.06 KB, 下载次数: 11)
12:39 上传
从上图我们可以看到，Yarn是一种统一资源管理方式，是从MRv1中的JobTracker分离出来的。这样的好处显而易见：资源共享，扩展性好等。
MRv1与Yarn的主要区别：在MRv1中，由JobTracker负责资源管理和作业控制，而Yarn中，JobTracker被分为两部分：ResourceManager（RM）和ApplicationMaster（AM）。如下图所示：
1.png (62.27 KB, 下载次数: 13)
12:39 上传
从上图中，我们可以清晰的看到 ，对于MRv1无论是资源管理里还是任务调度都是有JobTracker来完成得。这导致了，JobTracker负荷太大不便于管理和扩展而对于Yarn，我们看可以清晰地看到资源管理和任务调度被分为了两个部分：RM和AM。
Yarn与MRv1的差异对编程的影响：我们知道，MRv1主要由三部分组成：编程模型(API)、数据处理引擎(MapTask和ReduceTask)和运行环境(JobTracker和TaskTracker);Yarn继承了MRv1的编程模型和数据处理，改变的只是运行环境，所以对编程没有什么影响。
为了更好 的说明Yarn的资源管理，首先来看下Yarn的框架，如下图所示：
1.png (180.31 KB, 下载次数: 16)
12:56 上传
从上图可以看到 ，当客户向RM提交 作业时，由AM负责向RM提出资源申请，和向NameManager（NM）提出task执行 。也就是说 在这个过程中，RM负责资源调度，AM 负责任务调度。几点重要说明：RM负责整个集群的资源管理与调度；Nodemanager(NM)负责单个节点的资源管理与调度；NM定时的通过心跳的形式与RM进行通信，报告节点的健康状态与内存使用情况；AM通过与RM交互获取资源，然后然后通过与NM交互，启动计算任务。
下面对上面的内容通过内存资源配置进行详细说明：下面对上面的内容通过内存资源配置进行详细说明：
RM的内存资源配置，主要是通过下面的两个参数进行的（这两个值是Yarn平台特性，应在yarn-sit.xml中配置好）：
yarn.scheduler.minimum-allocation-mb
yarn.scheduler.maximum-allocation-mb
说明：单个容器可申请的最小与最大内存，应用在运行申请内存时不能超过最大值，小于最小值则分配最小值，从这个角度看，最小值有点想操作系统中的页。最小值还有另外一种用途，计算一个节点的最大container数目注：这两个值一经设定不能动态改变(此处所说的动态改变是指应用运行时)。
NM的内存资源配置，主要是通过下面两个参数进行的（这两个值是Yarn平台特性，应在yarn-sit.xml中配置） ：
yarn.nodemanager.resource.memory-mb
yarn.nodemanager.vmem-pmem-ratio
说明：每个节点可用的最大内存，RM中的两个值不应该超过此值。此数值可以用于计算container最大数目，即：用此值除以RM中的最小容器内存。虚拟内存率，是占task所用内存的百分比，默认值为2.1倍;注意：第一个参数是不可修改的，一旦设置，整个运行过程中不可动态修改，且该值的默认大小是8G，即使计算机内存不足8G也会按着8G内存来使用。
AM内存配置相关参数，此处以MapReduce为例进行说明（这两个值是AM特性，应在mapred-site.xml中配置），如下：
mapreduce.map.memory.mb
mapreduce.reduce.memory.mb
说明：这两个参数指定用于MapReduce的两个任务（Map and Reduce task）的内存大小，其值应该在RM中的最大最小container之间。如果没有配置则通过如下简单公式获得：
max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))
一般的reduce应该是map的2倍。注：这两个值可以在应用启动时通过参数改变；
AM中其它与内存相关的参数，还有JVM相关的参数，这些参数可以通过，如下选项配置：
mapreduce.map.java.opts
mapreduce.reduce.java.opts
说明：这两个参主要是为需要运行JVM程序（java、scala等）准备的，通过这两个设置可以向JVM中传递参数的，与内存有关的是，-Xmx，-Xms等选项。此数值大小，应该在AM中的map.mb和reduce.mb之间。
我们对上面的内容进行下总结，当配置Yarn内存的时候主要是配置如下三个方面：每个Map和Reduce可用物理内存限制；对于每个任务的JVM对大小的限制；虚拟内存的限制；
下面通过一个具体错误实例，进行内存相关说明，错误如下：
Container[pid=41884,containerID=container_8_284] is running beyond virtual memory limits. Current usage: 314.6 MB of 2.9 GB
8.7 GB of 6.2 GB virtual memory used. Killing container.
配置如下：
&property&
& && &&&&name&yarn.nodemanager.resource.memory-mb&/name&
& && &&&&value&100000&/value&
& & &/property&
& & &property&
& && &&&&name&yarn.scheduler.maximum-allocation-mb&/name&
& && &&&&value&10000&/value&
& & &/property&
& & &property&
& && &&&&name&yarn.scheduler.minimum-allocation-mb&/name&
& && &&&&value&3000&/value&
& & &/property&
& &&property&
& && &&&&name&mapreduce.reduce.memory.mb&/name&
& && &&&&value&2000&/value&
& & &/property&复制代码
通过配置我们看到，容器的最小内存和最大内存分别为：3000m和10000m，而reduce设置的默认值小于2000m，map没有设置，所以两个值均为3000m，也就是log中的“2.9 GB physical
memory used”。而由于使用了默认虚拟内存率(也就是2.1倍)，所以对于Map Task和Reduce Task总的虚拟内存为都为=6.2G。而应用的虚拟内存超过了这个数值，故报错 。解决办
法：在启动Yarn是调节虚拟内存率或者应用运行时调节内存大小。
在上Yarn的框架管理中，无论是AM从RM申请资源，还是NM管理自己所在节点的资源，都是通过container进行的。Container是Yarn的资源抽象，此处的资源包括内存和cup等。下面对
container，进行比较详细的介绍。为了是大家对container有个比较形象的认识，首先看下图：
1.png (80.54 KB, 下载次数: 11)
13:06 上传
从上图中我们可以看到，首先AM通过请求包ResourceRequest从RM申请资源，当获取到资源后，AM对其进行封装，封装成ContainerLaunchContext对象，通过这个对象，AM与NM进行通讯，
以便启动该任务。下面通过ResourceRequest、container和ContainerLaunchContext的protocol buffs定义，对其进行具体分析。
ResourceRequest结构如下：
message ResourceRequestProto {
optional PriorityProto priority = 1; // 资源优先级
optional string resource_name = 2; // 期望资源所在的host
optional ResourceProto capability = 3; // 资源量（mem、cpu）
optional int32 num_containers = 4; // 满足条件container个数
optional bool relax_locality = 5 ; //default =
对上面结构进行简要按序号说明：
2：在提交申请时，期望从哪台主机上获得，但最终还是AM与RM协商决定；
3：只包含两种资源，即：内存和cpu，申请方式：&memory_num,cup_num&
注：1、由于2与4并没有限制资源申请量，则AP在资源申请上是无限的。2、Yarn采用覆盖式资源申请方式，即：AM每次发出的资源请求会覆盖掉之前在同一节点且优先级相同的资源请求,
也就是说同一节点中相同优先级的资源请求只能有一个。
container结构：
message ContainerProto {
optional ContainerIdProto id = 1; //container id
optional NodeIdProto nodeId = 2; //container（资源）所在节点
optional string node_http_address = 3;
optional ResourceProto resource = 4; //分配的container数量
optional PriorityProto priority = 5; //container的优先级
optional hadoop.common.TokenProto container_token = 6; //container token，用于安全认证
}复制代码
注：每个container一般可以运行一个任务，当AM收到多个container时，将进一步分给某个人物。如：MapReduce
ContainerLaunchContext结构：
message ContainerLaunchContextProto {
repeated StringLocalResourceMapProto localResources = 1; //该Container运行的程序所需的在资源，例如：jar包
optional bytes tokens = 2;//Security模式下的SecurityTokens
repeated StringBytesMapProto service_data = 3;
repeated StringStringMapProto environment = 4; //Container启动所需的环境变量
repeated string command = 5; //该Container所运行程序的命令,比如运行的为java程序,即$JAVA_HOME/bin/java org.ourclassrepeated ApplicationACLMapProto application_ACLs = 6;//该Container所属的Application的访问
控制列表
}复制代码
下面结合一段代码，仅以ContainerLaunchContext为例进行描述(本应该写个简单的有限状态机的，便于大家理解，但时间不怎么充分)：
申请一个新的ContainerLaunchContext：
ContainerLaunchContext ctx = Records.newRecord(ContainerLaunchContext.class);
& && && & 填写必要的信息：
ctx.setEnvironment(...);
childRsrc.setResource(...);
ctx.setLocalResources(...);
ctx.setCommands(...);
启动任务：
startReq.setContainerLaunchContext(ctx);复制代码
最后对container进行如下总结：container是Yarn的资源抽象，封装了节点上的一些资源，主要是CPU与内存；container是AM向NM申请的，其运行是由AM向资源所在NM发起的，并最终运行
的。有两类container：一类是AM运行需要的container；另一类是AP为执行任务向RM申请的。
主题帖子积分
中级会员, 积分 315, 距离下一级还需 685 积分
中级会员, 积分 315, 距离下一级还需 685 积分
主题帖子积分
高级会员, 积分 2733, 距离下一级还需 2267 积分
高级会员, 积分 2733, 距离下一级还需 2267 积分
欢迎加入about云群 、 ，云计算爱好者群，亦可关注||
主题帖子积分
中级会员, 积分 200, 距离下一级还需 800 积分
中级会员, 积分 200, 距离下一级还需 800 积分
好文章，懂了一点
主题帖子积分
中级会员, 积分 925, 距离下一级还需 75 积分
中级会员, 积分 925, 距离下一级还需 75 积分
路过瞧瞧学习下哈！~
主题帖子积分
中级会员, 积分 553, 距离下一级还需 447 积分
中级会员, 积分 553, 距离下一级还需 447 积分
主题帖子积分
新手上路, 积分 24, 距离下一级还需 26 积分
新手上路, 积分 24, 距离下一级还需 26 积分
Current usage: 314.6 MB of 2.9 GB
8.7 GB of 6.2 GB virtual memory used.意思是当前2.9的物理内存使用了314MB，6.2G的虚拟内存使用了8.7G。
6.2G的虚拟内存如何计算得来？
mapreduce.reduce.memory.mb已配置reduce的内存限制为2000MB，map没有配置，由max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))算得3000MB，
QQ截图06.png (42.31 KB, 下载次数: 6)
13:47 上传
这个解释还是不太明白。
主题帖子积分
注册会员, 积分 100, 距离下一级还需 100 积分
注册会员, 积分 100, 距离下一级还需 100 积分
学习了，顶一个！！
主题帖子积分
新手上路, 积分 42, 距离下一级还需 8 积分
新手上路, 积分 42, 距离下一级还需 8 积分
学习了，顶一个！！
主题帖子积分
高级会员, 积分 1153, 距离下一级还需 3847 积分
高级会员, 积分 1153, 距离下一级还需 3847 积分
积极上进，爱好学习
经常参与各类话题的讨论，发帖内容较有主见
站长推荐 /4
会员注册不成功的原因
新手获取积分方法
hadoop3.0学习：零基础安装部署hadoop集群
about云课程：大数据日志实时分析
Powered by}