hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Dimiduk (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HBASE-13259) mmap() based BucketCache IOEngine
Date Wed, 15 Apr 2015 22:17:00 GMT

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

Nick Dimiduk commented on HBASE-13259:

bq.  mean could we test it with a size much larger than available memory? i.e., 100G RAM,
500G bucket cache on SSD?
If we only test it with a size smaller than available memory, then I think we need to beat
the offheap engine, not file engine(It is good if you can beat both of them)

[~Apache9], [~zeocio] either of you have a test rig to spin the above suggestions?

Patch is small and clean, looks good. One question: you changed in ByteBufferArray, all these
ugly {{if(filePath)}} checks. Does it make sense to subclass instead?

Any chance you've tested it with any of our myriad block cache options (cache on write, block
cache compression, evict on close)?

Sorry for letting your patch go stale. Mind cleaning it up for master and branch-1? We can
get some clean buildbot runs and commit it. Would be good to get this in for 1.1.0 with a
nice release note.

Oh, and [~zeocio] you may want to set configure your git user.email so you get proper attribution
in the repo (https://help.github.com/articles/setting-your-email-in-git/). Nice work!

> 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
>             Fix For: 2.2.0
>         Attachments: HBASE-13259-v2.patch, HBASE-13259.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

View raw message