You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "Appy (JIRA)" <ji...@apache.org> on 2015/12/23 06:57:46 UTC
[jira] [Updated] (HBASE-13142) [PERF] Reuse the
IPCUtil#buildCellBlock buffer
[ https://issues.apache.org/jira/browse/HBASE-13142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Appy updated HBASE-13142:
-------------------------
Assignee: stack (was: Liang Xie)
> [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
> Fix For: 2.0.0, 1.1.0
>
> Attachments: 13142.txt, 13142v2.txt, 13142v3.txt, 13142v5.0.98.txt, 13142v5.addendum.txt, 13142v5.txt, 13142v5.txt, buffers.svg, clean.svg, gc.png, gc_time_spent.png, hits.png, net.png, 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)