[
https://issues.apache.org/jira/browse/HBASE-21879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16774380#comment-16774380
]
ramkrishna.s.vasudevan commented on HBASE-21879:
------------------------------------------------
Thanks for the ping here folks. From the docs that we prepared when we did the
offheaping work we have the following points that were discussed
Netty's ByteBuf and NIO Bytebuffers- The comparison using JMH showed that NIO
BBs are 17% better. Ideally we should have seen similar performance but in the
netty version 4.0.23 had this reference counting and memory leak detection
mechanism which was actually not allowing the C2 compiler to do some proper
iniling of the code. How ever netty 4.0.4 had the feature to disable the
ResourceLeakDetector which brought the performance closer to the NIO case.
Still the reason that we went ahead with NIO - is indirectly a reason why this
JIRA is created- in the sense that since HDFS was already having an API to pass
NIO BB and read into the NIO BB, going with Netty ByteBuf would not allow that
to happen easily because of the HDFS API. The other advantage is that if we are
able to pass a offheap NIO BB we can avoid a copy to onheap once we read from
the DFS.
[~anoopsamjohn] - Is there anything I had missed out here.
But I think the idea of Netty doing ref counting helps in avoiding we doing the
ref counting which is adding some complexity. May be we had missed out some
options- if so it would be great to know about them. Good one.
> Read HFile's block to ByteBuffer directly instead of to byte for reducing
> young gc purpose
> ------------------------------------------------------------------------------------------
>
> Key: HBASE-21879
> URL: https://issues.apache.org/jira/browse/HBASE-21879
> Project: HBase
> Issue Type: Improvement
> Reporter: Zheng Hu
> Assignee: Zheng Hu
> Priority: Major
> Fix For: 3.0.0, 2.2.0, 2.3.0, 2.1.4
>
> Attachments: QPS-latencies-before-HBASE-21879.png,
> gc-data-before-HBASE-21879.png
>
>
> In HFileBlock#readBlockDataInternal, we have the following:
> {code}
> @VisibleForTesting
> protected HFileBlock readBlockDataInternal(FSDataInputStream is, long offset,
> long onDiskSizeWithHeaderL, boolean pread, boolean verifyChecksum,
> boolean updateMetrics)
> throws IOException {
> // .....
> // TODO: Make this ByteBuffer-based. Will make it easier to go to HDFS with
> BBPool (offheap).
> byte [] onDiskBlock = new byte[onDiskSizeWithHeader + hdrSize];
> int nextBlockOnDiskSize = readAtOffset(is, onDiskBlock, preReadHeaderSize,
> onDiskSizeWithHeader - preReadHeaderSize, true, offset +
> preReadHeaderSize, pread);
> if (headerBuf != null) {
> // ...
> }
> // ...
> }
> {code}
> In the read path, we still read the block from hfile to on-heap byte[], then
> copy the on-heap byte[] to offheap bucket cache asynchronously, and in my
> 100% get performance test, I also observed some frequent young gc, The
> largest memory footprint in the young gen should be the on-heap block byte[].
> In fact, we can read HFile's block to ByteBuffer directly instead of to
> byte[] for reducing young gc purpose. we did not implement this before,
> because no ByteBuffer reading interface in the older HDFS client, but 2.7+
> has supported this now, so we can fix this now. I think.
> Will provide an patch and some perf-comparison for this.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
