几个JobTracker优化的配置及解决JobTracker OOM的方法

系统上线两年多了，最近发现任务积压严重，当然与任务越来越多有关系，但也不能放任不管。
然后开始找原因，通过看日志，发现JT占用的内存挺大，虽然我内存给的20g，但也不能吃住不放啊，导致服务器LOAD值也有点偏高，所以断定是出在JT这里。

1.mapred.jobtracker.completeuserjobs.maximum
默认100
The maximum number of complete jobs per user to keep around before delegating them to the job history.
任务被扔到历史作业文件之前完成的任务最大数，也就是说每个用户完成队列中的最大任务数达100个后，将完成的任务放入作业历史文件中。
一般我们只会关注运行中的队列，所以可以考虑降低到10，减少内存资源占用，而且完成的Job也可以从history中看到信息。

2.mapred.reduce.slowstart.completed.maps
默认0.05
Fraction of the number of maps in the job which should be complete before reduces are scheduled for the job.
reduce开始之前map应该完成的数字
这个参数控制slowstart特性的时机，默认是在5%的map任务完成后，就开始调度reduce进程启动，开始copy过程。
如果reduce资源吃紧，可以考虑提高到0.5，等部分map结束后再启动reduce，避免资源死锁状态出现。

3.mapred.jobtracker.retirejob.interval
默认24*60*60*1000=86400000 24小时
每一个Job的生存周期
我根据我们的Job情况，可以考虑改为2*60*60*1000=7200000 2小时，一般3600000 1小时也就够了

4.mapred.jobtracker.retirejob.check
默认60 * 1000 1分钟
The check runs continually while the JobTracker is running. If a job is retired it is simply removed from the in-memory list of the JobTracker (it also removes all Tasks for the job etc.).
JobTracker定期检查Job是否过期的间隔时间
默认一分钟还可以，就不需要调整了

5.mapred.job.tracker.retiredjobs.cache.size
默认1000
The number of retired job status to keep in the cache.
作业状态为已不在执行的保留在内存中的量为1000
这个1000绝对的坑爹，过期的我还放这么多在内存中干嘛，为了降低内存开销，考虑可以降低为100

5.mapred.job.tracker.handler.count
默认是10
The number of server threads for the JobTracker. This should be roughly 4% of the number of tasktracker nodes.
这个是官方文档建议
If the NameNode and JobTracker are on big hardware, set dfs.namenode.handler.count to 64 and same with mapred.job.tracker.handler.count.
这个是cloudera建议，如果服务器硬件配置好，可以考虑改为64.
一般的主节点机器配置都不会太差，我们的虽然不好，但处理64应该没问题的。
网上还找到一个公式，mapred.job.tracker.handler.count = ln(#TT)*20
考虑可以改为64

配置修改调整后，选择了一个不是很繁忙的时间点重启了JobTracker，看到服务器的负载和JobTracker的内存占用立马下来了。第二天持续观察，发现内存占用降了10多倍，Load值也降低了2~3倍，任务提交和执行快了很多，之前积压的任务需要在下午左右才能跑完的任务，在上班前都完成了，问题解决。