[
https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15244749#comment-15244749
]
stack commented on HBASE-15536:
-------------------------------
bq. So we are using more CPUs with asyncwal?
I wouldn't put much weight on our wandering across CPUs. Probably not the thing
to focus on.
bq. What does the '2.597 GHz'
I don't know how 2.597GHz relates to 6,814,056,657,994 cycles.... Poked around
some... Should poke some more. Look at perf src?
bq. But usually these optimizations are only useful on loops and I can not find
a heavy loop in AsyncFSWAL (maybe the append loop in consume method?)...
Loops would be one aspect but others would be stuff like stalls while we have
to go to main memory or other than the immediate caches because of sub optimal
object layout and poor locality in the data, say, because the data structures
we use work against good alignment. Messing around in code, even minor
improvement in instructions per cycle makes for massive improvement in
throughput.
bq. Maybe we need to find the hot spots in AsyncFSWAL first?
At the macro level, aswyncfswall is more tthan 2x better than what was there
previous. That is more than enough to make it default.
I think that there is more speedup to be had here especially given there so few
moving parts after the nice work you've done in here but would take study in a
micro-benchmark context. We could set up a little jmh testbench for asyncwal?
I'd be more interested in a jmh micro-benchmark for studying our merge sort; a
different Cell layout and some study could get us a better scan throughput.
> Make AsyncFSWAL as our default WAL
> ----------------------------------
>
> Key: HBASE-15536
> URL: https://issues.apache.org/jira/browse/HBASE-15536
> Project: HBase
> Issue Type: Sub-task
> Reporter: Duo Zhang
>
> As it should be predicated on passing basic cluster ITBLL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
