[
https://issues.apache.org/jira/browse/HBASE-13142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-13142:
--------------------------
Attachment: 13142.txt
Adds a new class, ByteBufferReservoir. It is like ByteBufferPool over in Hadoop
only for a different use case (probably need a better name than BBR). Where
BBP keeps around BBs and you ask it to give a BB that is of or close to an
explicit size, BBR is about giving you a BB to use when you don't know size up
front. As the BBR works, we use a running average doing allocations and as time
goes by, all BBs in the BBR should stabilize. The target use case is buffer
reuse in RPC. If a buffer is extreme, we drop it.
In RpcServer, we create a reservoir. Calls, which are inner classes of
RpcServer on serverside, make use of the reservoir creating cellblocks. When
done, they recycle their buffers.
Adds a few tests.
Lets see if this works by running by hadoopqa.
Could add a reservoir clientside if this works out.
> [PERF] Reuse the IPCUtil#buildCellBlock buffer
> ----------------------------------------------
>
> Key: HBASE-13142
> URL: https://issues.apache.org/jira/browse/HBASE-13142
> Project: HBase
> Issue Type: Improvement
> Components: Performance
> Reporter: stack
> Assignee: stack
> Labels: beginner
> Attachments: 13142.txt, traces.2.svg, traces.svg
>
>
> Running some scan profiling, flight recorder was mildly fingering resize of
> the buffer allocated in IPCUtil#buildCellBlock as a point of contention. It
> was half-hearted blaming it for a few hundreds of ms over a five minute
> sampling with a few tens of instances showing.
> I tried then w/ flamegraph/lightweight profiler and this reported the buffer
> allocations taking 22% of our total CPU. See attachment trace.svg.
> I enabled TRACE-level logging on org.apache.hadoop.hbase.ipc.IPCUtil and
> indeed every allocation was doing a resize from initial allocation of 16k --
> the default up to 220k (this test returns ten randomly sized rows zipfian
> sized between 0 and 8k).
> Upping the allocation to 220k meant we now avoided the resize but the initial
> allocation was now blamed for 10% of allocations (see trace.2.svg attached).
> Lets do buffer reuse. Will save a bunch of allocation and CPU.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
