[jira] [Commented] (MAPREDUCE-5026) For shortening the time of TaskTracker heartbeat, decouple the statics collection operations
[ https://issues.apache.org/jira/browse/MAPREDUCE-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13695213#comment-13695213 ] sam liu commented on MAPREDUCE-5026: In Hadoop 2.x, there is no TaskTracker and JobTracker any more, and we could not apply current fix on Hadoop 2.x code base directly. Further more, in Hadoop 2.x, the similar feature is NodeManager reports heartbeat to ResourceManager, and it uses NodeStatusUpdaterImpl.java for this feature. But, when get the slave resource info, it use NodeStatusUpdaterImpl.getNodeStatus() which collects containers info, not the machine resource info(cpu, memory, disk, ...) like Hadoop 1.x. So, I suggest only apply this fix on Hadoop 1.x, not Hadoop 2.x. Experts, any comments? > For shortening the time of TaskTracker heartbeat, decouple the statics > collection operations > > > Key: MAPREDUCE-5026 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5026 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: performance, tasktracker >Affects Versions: 1.1.1 >Reporter: sam liu > Labels: patch > Fix For: 1.1.1 > > Attachments: HDFS-4527.patch, HDFS-4527.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > In each heartbeat of TaskTracker, it will calculate some system statics, like > the free disk space, available virtual/physical memory, cpu usage, etc. > However, it's not necessary to calculate all the statics in every heartbeat, > and this will consume many system resource and impace the performance of > TaskTracker heartbeat. Furthermore, the characteristics of system > properties(disk, memory, cpu) are different and it's better to collect their > statics in different intervals. > To reduce the latency of TaskTracker heartbeat, one solution is to decouple > all the system statics collection operations from it, and issue separate > threads to do the statics collection works when the TaskTracker starts. The > threads could be three: the first one is to collect cpu related statics in a > short interval; the second one is to collect memory related statics in a > normal interval; the third one is to collect disk related statics in a long > interval. And all the interval could be customized by the parameter > "mapred.stats.collection.interval" in the mapred-site.xml. At last, the > heartbeat could get values of system statics from the memory directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5026) For shortening the time of TaskTracker heartbeat, decouple the statics collection operations
[ https://issues.apache.org/jira/browse/MAPREDUCE-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604561#comment-13604561 ] sam liu commented on MAPREDUCE-5026: Hi Andrew, Sorry for replying late. In a simplest test: in one node cluster, the average time of executing 'HeartbeatResponse heartbeatResponse = transmitHeartBeat(now)' will spend 4.3 ms using the original TaskTracker.java, and the average time is from 1000 heartbeats. But, using the new TaskTracker.java, the time will be 2.1 ms in average. The efficiency improves a little more than 100%. > For shortening the time of TaskTracker heartbeat, decouple the statics > collection operations > > > Key: MAPREDUCE-5026 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5026 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: performance, tasktracker >Affects Versions: 1.1.1 >Reporter: sam liu > Labels: patch > Fix For: 1.1.1 > > Attachments: HDFS-4527.patch, HDFS-4527.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > In each heartbeat of TaskTracker, it will calculate some system statics, like > the free disk space, available virtual/physical memory, cpu usage, etc. > However, it's not necessary to calculate all the statics in every heartbeat, > and this will consume many system resource and impace the performance of > TaskTracker heartbeat. Furthermore, the characteristics of system > properties(disk, memory, cpu) are different and it's better to collect their > statics in different intervals. > To reduce the latency of TaskTracker heartbeat, one solution is to decouple > all the system statics collection operations from it, and issue separate > threads to do the statics collection works when the TaskTracker starts. The > threads could be three: the first one is to collect cpu related statics in a > short interval; the second one is to collect memory related statics in a > normal interval; the third one is to collect disk related statics in a long > interval. And all the interval could be customized by the parameter > "mapred.stats.collection.interval" in the mapred-site.xml. At last, the > heartbeat could get values of system statics from the memory directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5026) For shortening the time of TaskTracker heartbeat, decouple the statics collection operations
[ https://issues.apache.org/jira/browse/MAPREDUCE-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13604555#comment-13604555 ] sam liu commented on MAPREDUCE-5026: Hi Tian Hong, As a general rule, their rates of change are different: cpu changes faster than memory, and memory changes faster than disk. So the frequency of fetching cpu should be more than memory, and memory should be more than disk. Finally, we could reasonably reduce resource consumption on the node running tasktracker. > For shortening the time of TaskTracker heartbeat, decouple the statics > collection operations > > > Key: MAPREDUCE-5026 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5026 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: performance, tasktracker >Affects Versions: 1.1.1 >Reporter: sam liu > Labels: patch > Fix For: 1.1.1 > > Attachments: HDFS-4527.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > In each heartbeat of TaskTracker, it will calculate some system statics, like > the free disk space, available virtual/physical memory, cpu usage, etc. > However, it's not necessary to calculate all the statics in every heartbeat, > and this will consume many system resource and impace the performance of > TaskTracker heartbeat. Furthermore, the characteristics of system > properties(disk, memory, cpu) are different and it's better to collect their > statics in different intervals. > To reduce the latency of TaskTracker heartbeat, one solution is to decouple > all the system statics collection operations from it, and issue separate > threads to do the statics collection works when the TaskTracker starts. The > threads could be three: the first one is to collect cpu related statics in a > short interval; the second one is to collect memory related statics in a > normal interval; the third one is to collect disk related statics in a long > interval. And all the interval could be customized by the parameter > "mapred.stats.collection.interval" in the mapred-site.xml. At last, the > heartbeat could get values of system statics from the memory directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5026) For shortening the time of TaskTracker heartbeat, decouple the statics collection operations
[ https://issues.apache.org/jira/browse/MAPREDUCE-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13592076#comment-13592076 ] Tian Hong Wang commented on MAPREDUCE-5026: --- Hi sam Why you fetch the freeDiskSpace,cpu and memory value at the different speed rate? > For shortening the time of TaskTracker heartbeat, decouple the statics > collection operations > > > Key: MAPREDUCE-5026 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5026 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: performance, tasktracker >Affects Versions: 1.1.1 >Reporter: sam liu > Labels: patch > Fix For: 1.1.1 > > Attachments: HDFS-4527.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > In each heartbeat of TaskTracker, it will calculate some system statics, like > the free disk space, available virtual/physical memory, cpu usage, etc. > However, it's not necessary to calculate all the statics in every heartbeat, > and this will consume many system resource and impace the performance of > TaskTracker heartbeat. Furthermore, the characteristics of system > properties(disk, memory, cpu) are different and it's better to collect their > statics in different intervals. > To reduce the latency of TaskTracker heartbeat, one solution is to decouple > all the system statics collection operations from it, and issue separate > threads to do the statics collection works when the TaskTracker starts. The > threads could be three: the first one is to collect cpu related statics in a > short interval; the second one is to collect memory related statics in a > normal interval; the third one is to collect disk related statics in a long > interval. And all the interval could be customized by the parameter > "mapred.stats.collection.interval" in the mapred-site.xml. At last, the > heartbeat could get values of system statics from the memory directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MAPREDUCE-5026) For shortening the time of TaskTracker heartbeat, decouple the statics collection operations
[ https://issues.apache.org/jira/browse/MAPREDUCE-5026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13586136#comment-13586136 ] Andrew Wang commented on MAPREDUCE-5026: Hi Sam, Thanks for the patch. I moved your issue to MAPREDUCE, since the TaskTracker isn't a component of HDFS. A few minor comments: * Please rename "Statics" to "Statistics" in the code. * Could you provide some performance numbers, to quantify the before and after improvement? > For shortening the time of TaskTracker heartbeat, decouple the statics > collection operations > > > Key: MAPREDUCE-5026 > URL: https://issues.apache.org/jira/browse/MAPREDUCE-5026 > Project: Hadoop Map/Reduce > Issue Type: Improvement > Components: performance, tasktracker >Affects Versions: 1.1.1 >Reporter: sam liu > Labels: patch > Fix For: 1.1.1 > > Attachments: HDFS-4527.patch > > Original Estimate: 24h > Remaining Estimate: 24h > > In each heartbeat of TaskTracker, it will calculate some system statics, like > the free disk space, available virtual/physical memory, cpu usage, etc. > However, it's not necessary to calculate all the statics in every heartbeat, > and this will consume many system resource and impace the performance of > TaskTracker heartbeat. Furthermore, the characteristics of system > properties(disk, memory, cpu) are different and it's better to collect their > statics in different intervals. > To reduce the latency of TaskTracker heartbeat, one solution is to decouple > all the system statics collection operations from it, and issue separate > threads to do the statics collection works when the TaskTracker starts. The > threads could be three: the first one is to collect cpu related statics in a > short interval; the second one is to collect memory related statics in a > normal interval; the third one is to collect disk related statics in a long > interval. And all the interval could be customized by the parameter > "mapred.stats.collection.interval" in the mapred-site.xml. At last, the > heartbeat could get values of system statics from the memory directly. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
