[
https://issues.apache.org/jira/browse/HBASE-13142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14346822#comment-14346822
]
Anoop Sam John commented on HBASE-13142:
----------------------------------------
This, we were planning to do after the current tests on HBASE-11425. We might
need to calc the size required for the cell block and reuse available (already
created) buffers of enough size. We can keep the created buffers as soft ref or
so.
> [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: 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)
