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

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

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

[b]2.mapred.reduce.slowstart.completed.maps[/b]
默认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，避免资源死锁状态出现。

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

[b]4.mapred.jobtracker.retirejob.check[/b]
默认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是否过期的间隔时间
默认一分钟还可以，就不需要调整了

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

[b]5.mapred.job.tracker.handler.count[/b]
默认是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倍，任务提交和执行快了很多，之前积压的任务需要在下午左右才能跑完的任务，在上班前都完成了，问题解决。