Mailing-List: contact issues-help@hbase.apache.org; run by ezmlm
Precedence: bulk
Date: Mon, 22 Feb 2016 06:09:19 +0000 (UTC)
From: "Anoop Sam John (JIRA)" <jira@apache.org>
To: issues@hbase.apache.org
Message-ID: <JIRA.12782434.1426555241000.106874.1456121359860@Atlassian.JIRA>
In-Reply-To: <JIRA.12782434.1426555241000@Atlassian.JIRA>
References: <JIRA.12782434.1426555241000@Atlassian.JIRA>
 <JIRA.12782434.1426555241198@arcas>
Subject: [jira] [Commented] (HBASE-13259) mmap() based BucketCache IOEngine
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HBASE-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156520#comment-15156520 ] 

Anoop Sam John commented on HBASE-13259:
----------------------------------------

bq.buffers[i] = allocator.allocate(0, false);
This is just a 0 length dummy buffer.  Can be a HBB always.

{code}
if (directByteBuffer) {
77	          buffer = fileChannel.map(java.nio.channels.FileChannel.MapMode.READ_WRITE, pos * size,
78	              size);
79	        } else {
80	          buffer = fileChannel.map(java.nio.channels.FileChannel.MapMode.READ_WRITE, pos * size,
81	              0);
82	        }
{code}
On this engine, we will always call with 'directByteBuffer' true right? Can we throw Exception otherwise rather than creating 0 length BB?

It is bit ugly to have sync() API in ByteBufferAllocator.  
{code}
public void sync() throws IOException {
153	    if (fileChannel != null) {
154	      if(bufferArray != null) {
155	        bufferArray.sync();
156	      }
157	    }
158	  }
{code}
Can be call force() on fileChannel? Depending on that, we may not need sync() in ByteBufferArray as well.

// TODO: See if the SHARED mode can be created here
You checked. I think it is not advisable. It depends on the total data size and the page hit/miss is going to decide the perf.


> mmap() based BucketCache IOEngine
> ---------------------------------
>
>                 Key: HBASE-13259
>                 URL: https://issues.apache.org/jira/browse/HBASE-13259
>             Project: HBase
>          Issue Type: New Feature
>          Components: BlockCache
>    Affects Versions: 0.98.10
>            Reporter: Zee Chen
>            Assignee: Zee Chen
>            Priority: Critical
>             Fix For: 2.0.0, 1.3.0
>
>         Attachments: HBASE-13259-v2.patch, HBASE-13259.patch, HBASE-13259_v3.patch, ioread-1.svg, mmap-0.98-v1.patch, mmap-1.svg, mmap-trunk-v1.patch
>
>
> Of the existing BucketCache IOEngines, FileIOEngine uses pread() to copy data from kernel space to user space. This is a good choice when the total working set size is much bigger than the available RAM and the latency is dominated by IO access. However, when the entire working set is small enough to fit in the RAM, using mmap() (and subsequent memcpy()) to move data from kernel space to user space is faster. I have run some short keyval gets tests and the results indicate a reduction of 2%-7% of kernel CPU on my system, depending on the load. On the gets, the latency histograms from mmap() are identical to those from pread(), but peak throughput is close to 40% higher.
> This patch modifies ByteByfferArray to allow it to specify a backing file.
> Example for using this feature: set  hbase.bucketcache.ioengine to mmap:/dev/shm/bucketcache.0 in hbase-site.xml.
> Attached perf measured CPU usage breakdown in flames graph.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)