Hadoop 的mapreduce 的作业在运行过程中常常碰到一些这样的情况：
每一个map或者reduce只有30-40秒钟就结束
超大规模的job 时，通常会需要大量的map和reduce的slots 支持，但是job运行起来后，running的map和reduce并没有沾满集群的可用slots
当几乎所有的map和 reducers都在调度系统 中运行着，此时却有一个或者两个pending的map或者reduce，一直不跑，使得job一直无法正常结束。
对一个job的map数和reduce数的设定对一个job的运行是非常重要的，并且非常简单。以下是一些设置 这几个值的经验总结：
如果job的每个map或者 reduce task的运行时间都只有30-40秒钟，那么就减少该job的map或者reduce数，每一个task(map|reduce)的setup和加入到调度器中进行调度，这个中间的过程可能都要花费几秒钟，所以如果每个task都非常快就跑完了，就会在task的开始和结束的时候浪费太多的时间。JVM 的reuse方式也可以解决 这个问题。
如果某个input的文件 非常的大，比如 1TB，可以考虑将hdfs上的每个block size设大，比如设成256MB或者512MB，这样map和reduce的数据 可以减小。而且用户还可以通过命令 ：hadoop distcp -Ddfs.block.size=$[256*1024*1024] /path/to/inputdata /path/to/inputdata-with-largeblocks的方式来将已经存在咋hdfs上的数据进行大块化。然后删除掉原先的文件。
只要每个task都运行至少30-40秒钟，就可以考虑将mapper数扩大，比如集群的map slots为100个，那么就不要将一个job的mapper设成101，这样前100个map能够并行完成，而最后一个map要在前100个 mapper结束后才开始，因此在reduce开始运行前，map阶段的时间几乎就要翻倍。
尽量不要运行太多的reduce task。对大多数job来说，最好rduce的个数最多和集群中的reduce持平，或者比集群的 reduce slots小。这个对于小集群而言，尤其重要。
测试对比:
调整运行参数（ -Dmapred.max.split.size=$[16*1024*1024] ），或者在配置文件中对将 mapred.max.split.size设置成$[16*1024*1024] ，hadoop 中的wordcount任务的mapper数就会受到用户控制。当运行这种配置的任务时，每个task都会在10秒钟之内运行完，而从 jobtracker的webui上可以看到cluster的总体情况和job的情况，其中可以看到，running的map数频繁的在0-24之间波动。整个job17分52秒完成，比使用原始配置的job的运行时间的两倍还多。