1. 内存

hadoop为各个守护进程（namenode,secondarynamenode,jobtracker,datanode,tasktracker）统一分配的内存在hadoop-env.sh中设置，参数为HADOOP_HEAPSIZE，默认为1000M。

大部分情况下，这个统一设置的值可能并不适合。例如对于namenode节点，1000M的内存只能存储几百万个文件的数据块的引用。如果我想单独设置namenode的内存，可以通过HADOOP_NAMENODE_OPTS来设置。

export Hadoop_NAMENODE_OPTS="-Xmx15360m -Dcom.sun.management.jmxremote $HADOOP_NAMENODE_OPTS"

同样的，可以通过HADOOP_SECONDARYNAMENODE_OPTS来设置secondrynamenode的内存，使得它与namenode保持一致。

当然，还有HADOOP_DATANODE_OPTS、HADOOP_BALANCER_OPTS、HADOOP_JOBTRACKER_OPTS变量供你使用。

此外，tasktracker启动独立的子JVM以运行map和reduce任务，分配给每个子JVM的内存量由mapred.child.java.opts属性（mapred-site.xml）控制，默认值为200M。

2. 最大map任务数

一个tasktracker能够同时运行最大map任务数，由mapred.tasktracker.map.tasks.maximum属性（mapred-site.xml）控制，默认为2。

3. 最大reduce任务数

一个tasktracker能够同时运行最大reduce任务数，由mapred.tasktracker.reduce.tasks.maximum属（mapred-site.xml）性控制，默认为2。

Reduce任务的个数

正确的reduce任务的 个数应该是0.95或者1.75 ×（节点数 ×mapred.tasktracker.tasks.maximum参数值）。如果任务数是节点个数的0.95倍，那么所有的reduce任务能够在 map任务的输出传输结束后同时开始运行。如果任务数是节点个数的1.75倍，那么高速的节点会在完成他们第一批reduce任务计算之后开始计算第二批 reduce任务，这样的情况更有利于负载均衡。
目前reduce任务的数量 由于输出文件缓冲区大小(io.buffer.size × 2 ×reduce任务个数 << 堆大小)，被限制在大约1000个左右。直到能够指定一个固定的上限后，这个问题最终会被解决。

4. 小总结：计算节点的内存占用量。

默认情况下，一个同时运行了namenode，secondarynamenode和jobtracker的主节点，各自使用1000M内存，所以总计使用3000M。

默认情况下，一个从节点运行了如下守护进程：

• 1个datanode：默认占用1000M内存。
• 1个tasktracker：默认占用1000M内存。
• 最多2个map任务：2*200M=400M。
• 最多2个reduce任务：2*200M=400M。

即默认情况下，一个从节点需要使用2800M内存量。

例如，假设一台8个处理器的工作节点，每个处理器上运行2个进程，则可以将最大map任务数和最大reduce任务数分别设置成7（因为还有datanode和tasktracker进程，所以不能设置为8），各个JVM子任务可用内存设置为400M，则总内存开销=1000M(datanode)+1000M(tasktracker)+7*400M(map)+7*400M(reduce)=7600M

关于task内存配置有如下3个选项：

每个任务调用内存大小

• mapred.child.java.opts
• mapred.map.child.java.opts
• mapred.reduce.child.java.opts
• 通常我们会配置“mapred.child.java.opts”，但其实这个配置已经deprecated，却而代之的是：mapred.map.child.java.opts和mapred.reduce.child.java.opts两个配置，详情大家见JobConf类、