OK！这个重点的搞完之后我们在看看两个息息相关的参数，io.sort.mb和mapred.child.java.opts。因为每一个map或是reduce进程都是一个task，都会对应启动一个JVM，所以其实java.opts也与你启动的map和reduce数以及别的一些jvm敏感的参数有关。既然task运行在JVM里面，那么，我这里所要提到的sort.mb 也是分配在JVM中的，这个值是用来设置到底我一个map sort的可用buffer大小是多少，如果map在内存中sort的结果达到一个特定的值，就会被spill进入硬盘。具体这个值是等于mb*io.sort.spill.percent.。按照通常的设置方式，为了让jvm发挥最佳性能，一般设置JVM的最大可用内存量为mb设置的内存量的两倍。那么mb的内存量又根据什么设置呢？它主要是与你的一个map的结果数据量有关。如果一个map的结果数据量为600M，那么如果你设置的mb*io.sort.spill.percent.=200M，那么将进行3次spill进入硬盘，然后map完成后再将数据从硬盘上取出进行copy。所以，这个mb设置如果是600M的话，那么就不需要进行这次硬盘访问了，节省了很多时间。但是最大的问题是内存耗费很大。如果mb是600M，那么jvm.opts将需要设置为1G以上，那么，按照上例，你同时启动16个map和8个reduce 的话，那么你的内存至少应该有24G。所以，这里的设置也要慎重，因为毕竟你的服务器还要跑很多其他的服务。
下面就讲一下别的一些有影响的参数，按照一般的设置方法就可以。首先是针对磁盘和磁盘IO的，mapred.local.dir，这个参数最好设置的跟你的磁盘数相同，你的磁盘应该每一个磁盘都单独设置为RAID0，然后将所有磁盘配置成多路径在这个配置项下，那么HDFS在决定数据存储时会顺序循环存储，保证所有磁盘数据量的一致性，也提升了整体磁盘的IO速度。那么针对于网络，主要是有reduce和map同时运行时需要慎重考虑。mapred.reduce.parallel.copies与mapreduce.reduce.shuffle.maxfetchfailures这些参数都是对网络有一些影响的。第一个是reduce可以进行的最大并行拷贝线程数，这些线程会同时从不同的datanode上取map结果，而第二个出错重试次数过多对于很多我们的应用都是降低性能的一个问题。因为一般一个job重试了1次没有成功那基本以后无论怎么重试都是不会成功的，重试了不成功不要紧，关键是这个重试还大量的消耗系统的资源，让其他的线程可能也因为starvation 而进入重试状态，恶性循环了。如果说你的网络确实很成瓶颈，千兆网都达不到，那么建议打开mapred.compress.map.output压缩选项，并配置 mapred.map.output.compression.codec压缩编码格式，一般都会使用snappy，因为这种格式对于压缩和解压缩都相对较快。还有就是如果你的集群是异构的，有些机器性能好，有些差，那么建议打开mapred.reduce.tasks.speculative.execution推测性执行，有利于优化进程分配，提升集群性能。
如有不详或不对的地方，还请指正。