Uploaded image for project: 'HBase'
  1. HBase
  2. HBASE-15179 Cell/DBB end-to-end on the write-path
  3. HBASE-15788

Use Offheap ByteBuffers from BufferPool to read RPC requests.

VotersWatch issueWatchersLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Sub-task
    • Status: Closed
    • Major
    • Resolution: Fixed
    • None
    • 2.0.0
    • regionserver
    • None
    • Reviewed
    • Using the ByteBuffers from ByteBufferPool to read the request bytes at server. When the size of the request is smaller than 1/6th size of a BB in the pool, we will not use that but read into an on demand created, proper sized on heap ByteBuffer.

    Description

      Right now, when an RPC request reaches RpcServer, we read the request into an on demand created byte[]. When it is write request and including many mutations, the request size will be some what larger and we end up creating many temp on heap byte[] and causing more GCs.
      We have a ByteBufferPool of fixed sized off heap BBs. This is used at RpcServer while sending read response only. We can make use of the same while reading reqs also. Instead of reading whole of the request bytes into a single BB, we can read into N BBs (based on the req size). When BB is not available from pool, we will fall back to old way of on demand on heap byte[] creation.
      Remember these are off heap BBs. We read many proto objects from this read request bytes (like header, Mutation protos etc). Thanks to PB 3 and our shading work as it supports off heap BB now. Also the payload cells are also in these DBBs now. The codec decoder can work on these and create off heap BBs. Whole of our write path work with Cells now. At the time of addition to memstore, these cells are by default copied to MSLAB ( off heap based pooled MSLAB issue to follow this one). If MSLAB copy is not possible, we will do a copy to on heap byte[].
      One possible down side of this is :
      Before adding to Memstore, we do write to WAL. So the Cells created out of the offheap BBs (Codec#Decoder) will be used to write to WAL. The default FSHLog works with an OS obtained from DFSClient. This will have only standard OS write APIs which is byte[] based. So just to write to WAL, we will end up in temp on heap copy for each of the Cell. The other WAL imp (ie. AsynWAL) supports writing offheap Cells directly. We have work in progress to make AsycnWAL as default. Also we can raise HDFS req to support BB based write APIs in their client OS? Until then, will try for a temp workaround solution. Patch to say more on this.

      Attachments

        1. HBASE-15788.patch
          58 kB
          Anoop Sam John
        2. HBASE-15788_V4.patch
          64 kB
          Anoop Sam John
        3. HBASE-15788_V5.patch
          64 kB
          Anoop Sam John
        4. HBASE-15788_V6.patch
          80 kB
          Anoop Sam John
        5. HBASE-15788_V7.patch
          80 kB
          Anoop Sam John
        6. HBASE-15788_V8.patch
          80 kB
          Anoop Sam John
        7. HBASE-15788_v9.patch
          82 kB
          Anoop Sam John
        8. HBASE-15788_V10.patch
          82 kB
          Anoop Sam John

        Issue Links

        Activity

          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            anoop.hbase Anoop Sam John
            ram_krish ramkrishna.s.vasudevan
            Votes:
            0 Vote for this issue
            Watchers:
            10 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment