<property>
<name>mapred.tasktracker.map.tasks.maximum</name>
<value>12</value>
<final>true</final>
</property>
<property>
<name>mapred.tasktracker.reduce.tasks.maximum</name>
<value>4</value>
<final>true</final>
</property>
<property>
<name>mapred.map.child.java.opts</name>
<value>-Xmx1224M</value>
</property>
<property>
<name>mapred.reduce.child.java.opts</name>
<value>-Xmx2048M</value>
</property>
对于map槽位的内存占用，我的理解是这样，内存总数/CPU核数/4，上下可以浮动几百兆。
对于reduce槽位是内存总数/cpu核数/2。
然后简单说下调度器的问题，hadoop默认的调度器是FIFO，就是先入先出，通常来说，这就比较够用了。但是如果集群规模较小，计算任务又比较多，还需要细分不同任务的槽位分配，就还是配置其他的调度器比较好。
常用的有两种第三方调度器，yahoo开发的Capacity Scheduler和Facebook贡献的Fair Scheduler。翻译过来叫计算能力调度器和公平调度器，可能大家听公平调度器听的比较多，不过目前我们公司主要是用计算能力调度器。
因为配置的XML太长，我就不贴了，需要了解计算能力调度器的配置方法，可以访问我的同事老赵的技术文章。
在我们的应用场景里，计算能力被分为了3类，每个分类的map/reudce槽位数是不同的，根据统计平时的计算量来固定分配的槽位数。default，rush，和hive，其中普通的streaming的计算方式放入default的分类中执行，日志清洗和入库单独使用rush分类，hive，顾名思义，就是给hive数据库单独使用的。这个分配的map/reduce是最多的。平时定时任务的70%左右都是用hive跑的，临时数据查询95%依赖hive。
这样做的好处是计算任务的计算能力被隔离，互不干扰。可根据业务需求进行分类。避免任务抢占造成的资源大量消耗。