JobTracker心跳优化
2013-08-21 10:01
260 查看
马上要开始第二阶段优化了,赶快把第一阶段优化内容及结果贴下。
•背景
–繁忙时段98%~100%的handler线程被BLOCK
–RPC请求堆积
•Profiling工具 (定位瓶颈)
–jstack线上环境使用
–yjp测试环境使用
优化一:避免频繁调用加锁方法
•500次连续jstack结果分析
–jt.getTasksToKill:15631.2%
-- tip.shouldClose 155 99.3%
-- tip.isComplete 155 100%
•synchronized方法比non-synchronized方法慢10-15倍
•优化方法:避免调用加锁的TIP::isComplete()
优化前,TIP::isComplete()方法占总CPU时间达36%:
优化后:已经在图中消失,即比例非常小。
优化二:避免比较JobID
优化前,TIP::shouldClose()方法占到了总CPU时间的19%
•优化方案:
–TreeMap增加Comparator
–新增只比较id的tip.isComplete(tid)方法
优化后只有1%了:
优化三:降低JT::getTasksToKill()方法的时间复杂度
•优化getTasksToKill()
–优化前每次心跳遍历TaskTracker上所有task
–优化后每次心跳遍历TaskTracker上running
task
•TaskTracker上completed
tasks >> running task
优化后,心跳已经不占主要操作:
顺便说下优化三是非常给力的,举个例子:
一个1w个map+5k个reduce的作业,当执行reduce时,map全部处于完成状态。这段时间每次心跳都要遍历这1w的map;
而tasktracker上running tasks的个数的最大值是个常数,也就是slots的配置。
因此这个改动是可以理解为复杂度降低了一个数量级。
优化四:降低Scheduler::updateTaskCounts()时间复杂度
•优化Scheduler.updateTaskCounts()
–优化前:遍历job的每个task统计runningMaps|Reduces & neededMaps|Reduces
–优化后:直接从JobInProgress中读取上述统计值
优化总结
•根本原因:
–单点
–心跳需要持有JobTracker大锁
•优化的关键是定位瓶颈
•消除一个瓶颈后,很快会出现下一个瓶颈
•终极方案:mr2 (0.23)
本次优化的最大成果是,在2000台集群上成功启动了TaskTracker的oob心跳。
原文地址:http://blog.csdn.net/liangliyin/article/details/7532790
•背景
–繁忙时段98%~100%的handler线程被BLOCK
–RPC请求堆积
•Profiling工具 (定位瓶颈)
–jstack线上环境使用
–yjp测试环境使用
优化一:避免频繁调用加锁方法
•500次连续jstack结果分析
–jt.getTasksToKill:15631.2%
-- tip.shouldClose 155 99.3%
-- tip.isComplete 155 100%
•synchronized方法比non-synchronized方法慢10-15倍
•优化方法:避免调用加锁的TIP::isComplete()
优化前,TIP::isComplete()方法占总CPU时间达36%:
优化后:已经在图中消失,即比例非常小。
优化二:避免比较JobID
优化前,TIP::shouldClose()方法占到了总CPU时间的19%
•优化方案:
–TreeMap增加Comparator
–新增只比较id的tip.isComplete(tid)方法
优化后只有1%了:
优化三:降低JT::getTasksToKill()方法的时间复杂度
•优化getTasksToKill()
–优化前每次心跳遍历TaskTracker上所有task
–优化后每次心跳遍历TaskTracker上running
task
•TaskTracker上completed
tasks >> running task
优化后,心跳已经不占主要操作:
顺便说下优化三是非常给力的,举个例子:
一个1w个map+5k个reduce的作业,当执行reduce时,map全部处于完成状态。这段时间每次心跳都要遍历这1w的map;
而tasktracker上running tasks的个数的最大值是个常数,也就是slots的配置。
因此这个改动是可以理解为复杂度降低了一个数量级。
优化四:降低Scheduler::updateTaskCounts()时间复杂度
•优化Scheduler.updateTaskCounts()
–优化前:遍历job的每个task统计runningMaps|Reduces & neededMaps|Reduces
–优化后:直接从JobInProgress中读取上述统计值
优化总结
•根本原因:
–单点
–心跳需要持有JobTracker大锁
•优化的关键是定位瓶颈
•消除一个瓶颈后,很快会出现下一个瓶颈
•终极方案:mr2 (0.23)
本次优化的最大成果是,在2000台集群上成功启动了TaskTracker的oob心跳。
原文地址:http://blog.csdn.net/liangliyin/article/details/7532790
相关文章推荐
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- Hadoop源码分析24 JobTracker启动和心跳处理流程
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- TaskTracker向JobTracker发送心跳时的问题
- Hadoop源码分析27 JobTracker空载处理心跳
- TaskTracker向JobTracker发送心跳时的问题
- hadoop运行原理之Job运行(四) JobTracker端心跳机制分析
- TaskTracker向JobTracker发送心跳时的问题
- hadoop之MapReduce框架JobTracker端心跳机制分析(源码分析第七篇) 推荐
- TaskTracker向JobTracker发送心跳时的问题
- MapReduce(十四): JobTracker的心跳处理