hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "stack (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-13142) [PERF] Reuse the IPCUtil#buildCellBlock buffer
Date Fri, 06 Mar 2015 19:11:40 GMT

     [ https://issues.apache.org/jira/browse/HBASE-13142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

stack updated HBASE-13142:
--------------------------
    Attachment: hits.png
                gc.png
                net.png
                gc_time_spent.png

Looking at graphs, claims of 20% more throughput is a bit much.  Lets say 10%.  I've posted
hits (next count at the server), gc profile (two graphs, one of incidence counts + time and
one of time only because the former hard to see time spent). Also a network traffic graph.

More pictures coming.

> [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.txt, 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)

Mime
View raw message