mapreduce设置map个数_mapreduce设置map内存-EDA365

嵌入式 > 嵌入式开发 > 详情

mapreduce设置map个数_mapreduce设置map内存

发布时间：

标签:
mapreduce
MAP

　　摘要

　　在map阶段读取数据前，FileInputFormat会将输入文件分割成split。split的个数决定了map的个数。

　　影响map个数，即split个数的因素主要有：

　　1）HDFS块的大小，即HDFS中dfs.block.size的值。如果有一个输入文件为1024m，当块为

　　256m时，会被划分为4个split；当块为128m时，会被划分为8个split。

　　2）文件的大小。当块为128m时，如果输入文件为128m，会被划分为1个split；当块为256m，

　　会被划分为2个split。

　　3）文件的个数。FileInputFormat按照文件分割split，并且只会分割大文件，即那些大小超过

　　HDFS块的大小的文件。如果HDFS中dfs.block.size设置为64m，而输入的目录中文件有100个，则

　　划分后的split个数至少为100个。

　　4）splitsize的大小。分片是按照splitszie的大小进行分割的，一个split的大小在没有设置的情况下，

　　默认等于hdfs block的大小。但应用程序可以通过两个参数来对splitsize进行调节。

　　map个数的计算公式如下：

　　1，splitsize=max（minimumsize，min（maximumsize，blocksize））。

　　如果没有设置minimumsize和maximumsize，splitsize的大小默认等于blocksize

　　2、计算公式

　　计算过程可以简化为如下的公式，详细算法可以参照FileInputSplit类中的getSplits方法

　　total_split ;

　　for（file ：输入目录中的每个文件）

　　{

　　file_split = 1;

　　if（file.size》splitsize）

　　{

　　file_split=file_size/splitsize;

　　}

　　total_split+=file_split;

　　}

　　关于配置MapReduce内存

　　1. Container内存使用的监控

　　NodeManager作为Yarn运行中的一个守护进程，其中一个职责是监控运行在节点上的container，通常包含每个容器的内存使用。

　　为监控容器的内存使用情况，在Yarn的配置文件yarn-site.xml中配置yarn.nodemanager.container-monitor.interval-ms属性遍历当前正在运行的容器，计算进程树（process tree，即每个容器中所有的子进程），对于每个进程检查/proc/《pid》/stat文件（其中pid为容器的进程ID），抽取出物理内存（又称RSS）和虚拟内存（又称VSZ或VSIZE）。

　　配置yarn-nodemanager.vmem-check-enabled控制虚拟检查是否要求打开，然后Yarn将抽取出来的容器及其子进程的VSIZE加起来和容器最大允许使用的虚拟内存进行比较。最大允许使用的虚拟内存是容器最大可使用的物理内存×yarn.nodemanager.vmem-pmem-ratio（默认值为2.1）。所以，如果Yarn容器配置的最大可用物理内存为2GB，然后乘以2.1即为容器最大可用的虚拟内存4.2G。

　　配置yarn.nodemanager.pmem-check-enabled属性控制物理内存检查是否被打开，然后Yarn将抽取出来的容器及其子进程的加起来和容器最大允许使用的物理内存进行比较。

　　如果物理内存或者虚拟内存其中一个使用大于最大允许使用情况，Yarn会将kill该容器。并在日志打印以下日志：

　　Application application_1409135750325_48141 failed 2 times due to AM Container for

　　appattempt_1409135750325_48141_000002 exited with exitCode： 143 due to： Container

　　［pid=4733，containerID=container_1409135750325_48141_02_000001］ is running beyond physical memory limits.

　　Current usage： 2.0 GB of 2 GB physical memory used; 6.0 GB of 4.2 GB virtual memory used. Killing container.