Hadoop HDFS
  1. Hadoop HDFS
  2. HDFS-1353

Remove most of getBlockLocation optimization

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.21.0
    • Fix Version/s: 0.22.0
    • Component/s: namenode
    • Labels:
      None
    • Hadoop Flags:
      Reviewed

      Description

      <This description is not valid. See comment.>
      HDFS-1081 optimized the number of block access tokens (BATs) created in a single call to getBlockLocations, as this is an expensive operation. However, that JIRA put off another optimization which was then made possible, which is to just send a single block access token across the wire (and maintain a single BAT on the client side). This JIRA is for implementing that optimization. Since a single BAT is generated for all the blocks, we just write that single BAT to the wire, rather than writing n BATs for n blocks, as is currently done. This turns out to be a useful optimization for files with very large numbers of blocks, as the new lone BAT is much larger than was a BAT previously.

      1. HDFS-1353-y20-2.patch
        13 kB
        Jakob Homan
      2. HDFS-1353-y20.patch
        22 kB
        Jakob Homan
      3. HDFS-1353-optmized-wire-not-to-be-committed.patch
        17 kB
        Jakob Homan
      4. HDFS-1353.patch
        17 kB
        Jakob Homan
      5. Benchmarking results.xlsx
        73 kB
        Jakob Homan

        Issue Links

          Activity

          Jakob Homan created issue -
          Jakob Homan made changes -
          Field Original Value New Value
          Fix Version/s 0.21.1 [ 12315271 ]
          Fix Version/s 0.22.0 [ 12314241 ]
          Affects Version/s 0.21.0 [ 12314046 ]
          Affects Version/s 0.22.0 [ 12314241 ]
          Hide
          Jakob Homan added a comment -

          While benchmarking this new patch, originally an addendum to HDFS-1081, we determined that 1081's original benchmarks were in error. getBlockLocations was not the culprit in the performance degradation. 1081 didn't do any damage to speed, and with this addendum, actually does give some benefit for files with moderate numbers of blocks (see to-be-attached benchmarks). However, since getBL isn't really a slow method, these gains aren't worth the extra complexity they introduce. I'll upload the on-the-wire optimization patch, in case it becomes useful at some point, but I'm going to use this JIRA to roll back most of 1081, excluding some byte-array allocating that we can easily cache. ...sigh.

          Show
          Jakob Homan added a comment - While benchmarking this new patch, originally an addendum to HDFS-1081 , we determined that 1081's original benchmarks were in error. getBlockLocations was not the culprit in the performance degradation. 1081 didn't do any damage to speed, and with this addendum, actually does give some benefit for files with moderate numbers of blocks (see to-be-attached benchmarks). However, since getBL isn't really a slow method, these gains aren't worth the extra complexity they introduce. I'll upload the on-the-wire optimization patch, in case it becomes useful at some point, but I'm going to use this JIRA to roll back most of 1081, excluding some byte-array allocating that we can easily cache. ...sigh.
          Jakob Homan made changes -
          Summary Optimize number of block access tokens returned by getBlockLocations Remove most of getBlockLocation optimization
          Description HDFS-1081 optimized the number of block access tokens (BATs) created in a single call to getBlockLocations, as this is an expensive operation. However, that JIRA put off another optimization which was then made possible, which is to just send a single block access token across the wire (and maintain a single BAT on the client side). This JIRA is for implementing that optimization. Since a single BAT is generated for all the blocks, we just write that single BAT to the wire, rather than writing n BATs for n blocks, as is currently done. This turns out to be a useful optimization for files with very large numbers of blocks, as the new lone BAT is much larger than was a BAT previously. <This description is not valid. See comment.>
          HDFS-1081 optimized the number of block access tokens (BATs) created in a single call to getBlockLocations, as this is an expensive operation. However, that JIRA put off another optimization which was then made possible, which is to just send a single block access token across the wire (and maintain a single BAT on the client side). This JIRA is for implementing that optimization. Since a single BAT is generated for all the blocks, we just write that single BAT to the wire, rather than writing n BATs for n blocks, as is currently done. This turns out to be a useful optimization for files with very large numbers of blocks, as the new lone BAT is much larger than was a BAT previously.
          Hide
          Jakob Homan added a comment -

          Benchmarks of original patch, which optimized the on-the-wire combined block tokens.

          Show
          Jakob Homan added a comment - Benchmarks of original patch, which optimized the on-the-wire combined block tokens.
          Jakob Homan made changes -
          Attachment Benchmarking results.xlsx [ 12453822 ]
          Hide
          Jakob Homan added a comment -

          Patch for y20. Not for commit here.

          Show
          Jakob Homan added a comment - Patch for y20. Not for commit here.
          Jakob Homan made changes -
          Attachment HDFS-1353-y20.patch [ 12453823 ]
          Hide
          Jakob Homan added a comment -

          Patch for trunk and 21.

          Show
          Jakob Homan added a comment - Patch for trunk and 21.
          Jakob Homan made changes -
          Attachment HDFS-1353.patch [ 12453824 ]
          Hide
          Jakob Homan added a comment -

          Submitting patch.

          Show
          Jakob Homan added a comment - Submitting patch.
          Jakob Homan made changes -
          Status Open [ 1 ] Patch Available [ 10002 ]
          Fix Version/s 0.22.0 [ 12314241 ]
          Hide
          Jitendra Nath Pandey added a comment -

          In BlockTokenIdentifier constructor, should we check for non-zero blockId? Earlier we checked for non-null blockIds array.

          +1 otherwise, pending hudson.

          Show
          Jitendra Nath Pandey added a comment - In BlockTokenIdentifier constructor, should we check for non-zero blockId? Earlier we checked for non-null blockIds array. +1 otherwise, pending hudson.
          Hide
          Jakob Homan added a comment -

          In BlockTokenIdentifier constructor, should we check for non-zero blockId? Earlier we checked for non-null blockIds array.

          The blockID is a random number, so it might be 0, so we don't need to check that. Thanks.

          Show
          Jakob Homan added a comment - In BlockTokenIdentifier constructor, should we check for non-zero blockId? Earlier we checked for non-null blockIds array. The blockID is a random number, so it might be 0, so we don't need to check that. Thanks.
          Hide
          Jakob Homan added a comment -

          Ran tests manually. All past except known bad TestHDFSTrash and TestFileConcurrentReader. Test-patch:

               [exec] -1 overall.  
               [exec] 
               [exec]     +1 @author.  The patch does not contain any @author tags.
               [exec] 
               [exec]     +1 tests included.  The patch appears to include 3 new or modified tests.
               [exec] 
               [exec]     -1 javadoc.  The javadoc tool appears to have generated 1 warning messages.
               [exec] 
               [exec]     +1 javac.  The applied patch does not increase the total number of javac compiler warnings.
               [exec] 
               [exec]     +1 findbugs.  The patch does not introduce any new Findbugs warnings.
               [exec] 
               [exec]     +1 release audit.  The applied patch does not increase the total number of release audit warnings.
               [exec] 
               [exec]     +1 system tests framework.  The patch passed system tests framework compile.
          

          Javadoc warning has been around and is bogus. I plan to commit this.

          Show
          Jakob Homan added a comment - Ran tests manually. All past except known bad TestHDFSTrash and TestFileConcurrentReader. Test-patch: [exec] -1 overall. [exec] [exec] +1 @author. The patch does not contain any @author tags. [exec] [exec] +1 tests included. The patch appears to include 3 new or modified tests. [exec] [exec] -1 javadoc. The javadoc tool appears to have generated 1 warning messages. [exec] [exec] +1 javac. The applied patch does not increase the total number of javac compiler warnings. [exec] [exec] +1 findbugs. The patch does not introduce any new Findbugs warnings. [exec] [exec] +1 release audit. The applied patch does not increase the total number of release audit warnings. [exec] [exec] +1 system tests framework. The patch passed system tests framework compile. Javadoc warning has been around and is bogus. I plan to commit this.
          Hide
          Jakob Homan added a comment -

          For completeness' sake, here's the planned optimizations referenced in the spreadsheet... Not to be committed.

          Show
          Jakob Homan added a comment - For completeness' sake, here's the planned optimizations referenced in the spreadsheet... Not to be committed.
          Jakob Homan made changes -
          Hide
          Jakob Homan added a comment -

          I've committed this to trunk. Resolving as fixed.

          Show
          Jakob Homan added a comment - I've committed this to trunk. Resolving as fixed.
          Jakob Homan made changes -
          Status Patch Available [ 10002 ] Resolved [ 5 ]
          Hadoop Flags [Reviewed]
          Fix Version/s 0.21.1 [ 12315271 ]
          Resolution Fixed [ 1 ]
          Hide
          Hudson added a comment -

          Integrated in Hadoop-Hdfs-trunk-Commit #380 (See https://hudson.apache.org/hudson/job/Hadoop-Hdfs-trunk-Commit/380/)
          HDFS-1353. Remove most of getBlockLocation optimization.

          Show
          Hudson added a comment - Integrated in Hadoop-Hdfs-trunk-Commit #380 (See https://hudson.apache.org/hudson/job/Hadoop-Hdfs-trunk-Commit/380/ ) HDFS-1353 . Remove most of getBlockLocation optimization.
          Hide
          Jakob Homan added a comment -

          Uploading updated patch. We changed the fix a bit to not bump the RPC protocol version since it's a minor fix. Not for commit to Apache.

          Show
          Jakob Homan added a comment - Uploading updated patch. We changed the fix a bit to not bump the RPC protocol version since it's a minor fix. Not for commit to Apache.
          Jakob Homan made changes -
          Attachment HDFS-1353-y20-2.patch [ 12456526 ]
          Jeff Hammerbacher made changes -
          Link This issue is related to HDFS-1081 [ HDFS-1081 ]
          Konstantin Shvachko made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Patch Available Patch Available
          9d 19h 59m 1 Jakob Homan 03/Sep/10 21:35
          Patch Available Patch Available Resolved Resolved
          4h 7m 1 Jakob Homan 04/Sep/10 01:42
          Resolved Resolved Closed Closed
          464d 5h 36m 1 Konstantin Shvachko 12/Dec/11 06:19

            People

            • Assignee:
              Jakob Homan
              Reporter:
              Jakob Homan
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development