HBase
  1. HBase
  2. HBASE-2500

Block indexes and meta blocks should be put into the LRU

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: regionserver

      Description

      Currently we are not tracking the heap usage of block indexes. We're just relying on the fact that we leave a large percentage of total heap as part of "everything else" not in memstores or the block cache. The "everything else" portion should be left for ephemeral/transient memory usage, not long-lived objects like block indexes. Introduction of blooms will extend this issue to meta blocks in general.

      All of this should be moved into an LRU. Either the existing block cache LRU or a new LRU.

        Issue Links

          Activity

          Hide
          Jean-Daniel Cryans added a comment -

          This was done as part of the HFileV2 work.

          Show
          Jean-Daniel Cryans added a comment - This was done as part of the HFileV2 work.
          Hide
          stack added a comment -

          Moving out of 0.92. Move it back in if you think differently.

          Show
          stack added a comment - Moving out of 0.92. Move it back in if you think differently.
          Hide
          stack added a comment -

          Moving out of 0.92. Move it back in if you think differently.

          Show
          stack added a comment - Moving out of 0.92. Move it back in if you think differently.
          Hide
          Jonathan Gray added a comment -

          This really should be done, but punting to 0.92 because won't be done in time for 0.90.

          Show
          Jonathan Gray added a comment - This really should be done, but punting to 0.92 because won't be done in time for 0.90.
          Hide
          stack added a comment -

          Bulk move of 0.20.5 issues into 0.21.0 after vote that we merge branch into TRUNK up on list.

          Show
          stack added a comment - Bulk move of 0.20.5 issues into 0.21.0 after vote that we merge branch into TRUNK up on list.
          Hide
          stack added a comment -

          I like this.

          Show
          stack added a comment - I like this.
          Hide
          Jonathan Gray added a comment -

          I guess there are also additional long-lived references to the block indexes that would need to be removed in order to actually evict?

          One way to do this would be to have a special eviction method called when evicting block index blocks. Shouldn't be so hard to do in the block cache if we give them their own type/priority.

          Show
          Jonathan Gray added a comment - I guess there are also additional long-lived references to the block indexes that would need to be removed in order to actually evict? One way to do this would be to have a special eviction method called when evicting block index blocks. Shouldn't be so hard to do in the block cache if we give them their own type/priority.
          Hide
          ryan rawson added a comment -

          Right now the block index does not have multiple sub-blocks. Even if it did, any operation requiring the block index would have to load the entire block index because it does a binary search. The block index is not really designed to be usable "in-situ" like the data blocks, so something extra fancy with callbacks when blocks are evicted might be required.

          Show
          ryan rawson added a comment - Right now the block index does not have multiple sub-blocks. Even if it did, any operation requiring the block index would have to load the entire block index because it does a binary search. The block index is not really designed to be usable "in-situ" like the data blocks, so something extra fancy with callbacks when blocks are evicted might be required.
          Hide
          Jonathan Gray added a comment -

          My preference would be to add all of these to the existing block cache LRU. The open question then would be whether they are treated like other normal data blocks, or whether we add additional block types. The design of the LRU actually makes it quite easy to add additional types (currently there is single access block, multiple access block, and in-memory block), and there is not much overhead involved. The additional overhead is done in the background eviction thread so doesn't add anything to the put/get methods.

          If there was a new block type or two, like "index" and/or "meta", then these would be able to have their own slice of the total block cache pie. The LRU gives each of the different block types their own percentage of the total LRU size. Each is able to grow above it's slice if others are under-utilized, the LRU just guarantees that during an eviction that block type will be given at least the specified slice size.

          I think we'll also need to add code to re-fetch block indexes / meta blocks if they are not in the block cache.

          Show
          Jonathan Gray added a comment - My preference would be to add all of these to the existing block cache LRU. The open question then would be whether they are treated like other normal data blocks, or whether we add additional block types. The design of the LRU actually makes it quite easy to add additional types (currently there is single access block, multiple access block, and in-memory block), and there is not much overhead involved. The additional overhead is done in the background eviction thread so doesn't add anything to the put/get methods. If there was a new block type or two, like "index" and/or "meta", then these would be able to have their own slice of the total block cache pie. The LRU gives each of the different block types their own percentage of the total LRU size. Each is able to grow above it's slice if others are under-utilized, the LRU just guarantees that during an eviction that block type will be given at least the specified slice size. I think we'll also need to add code to re-fetch block indexes / meta blocks if they are not in the block cache.

            People

            • Assignee:
              Unassigned
              Reporter:
              Jonathan Gray
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development