Hadoop Map/Reduce
  1. Hadoop Map/Reduce
  2. MAPREDUCE-5026

For shortening the time of TaskTracker heartbeat, decouple the statics collection operations

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 1.1.1
    • Fix Version/s: 1.1.1
    • Component/s: performance, tasktracker
    • Labels:

      Description

      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.

      1. HDFS-4527.patch
        6 kB
        sam liu
      2. HDFS-4527.patch
        6 kB
        sam liu

        Activity

        Hide
        sam liu added a comment -

        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?

        Show
        sam liu added a comment - 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?
        Hide
        sam liu added a comment -

        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%.

        Show
        sam liu added a comment - 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%.
        Hide
        sam liu added a comment -

        replace Statics with Statistics

        Show
        sam liu added a comment - replace Statics with Statistics
        Hide
        sam liu added a comment -

        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.

        Show
        sam liu added a comment - 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.
        Hide
        Tian Hong Wang added a comment -

        Hi sam
        Why you fetch the freeDiskSpace,cpu and memory value at the different speed rate?

        Show
        Tian Hong Wang added a comment - Hi sam Why you fetch the freeDiskSpace,cpu and memory value at the different speed rate?
        Hide
        Andrew Wang added a comment -

        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?
        Show
        Andrew Wang added a comment - 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?
        Hide
        sam liu added a comment -

        Added a draft patch for reference

        Show
        sam liu added a comment - Added a draft patch for reference

          People

          • Assignee:
            Unassigned
            Reporter:
            sam liu
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Time Tracking

              Estimated:
              Original Estimate - 24h
              24h
              Remaining:
              Remaining Estimate - 24h
              24h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development