[
https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
stack updated HBASE-16890:
--------------------------
Attachment: Screen Shot 2016-10-25 at 7.39.48 PM.png
Screen Shot 2016-10-25 at 7.39.07 PM.png
Screen Shot 2016-10-25 at 7.34.47 PM.png
classic.svg
async.svg
Here are some flame graphs of classic vs async. We are in consume a good while
of the cpu spent.
Screenshot shows call tree in JFR for same async.svg period.
These are time spent when sampling. Hard to get a good handle on
synchronize/lock friction. One view is if an item shows up frequently in the
thread contention view. Again we are sampling so if it shows here my thinking
is that it must be a pain point (JFR does the unsafe safe point sampling so its
view is a bit closer to what is going on). I include two images from same jfr
compares of the contention windows for async and classic.
> Analyze the performance of AsyncWAL and fix the same
> ----------------------------------------------------
>
> Key: HBASE-16890
> URL: https://issues.apache.org/jira/browse/HBASE-16890
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Affects Versions: 2.0.0
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Fix For: 2.0.0
>
> Attachments: Screen Shot 2016-10-25 at 7.34.47 PM.png, Screen Shot
> 2016-10-25 at 7.39.07 PM.png, Screen Shot 2016-10-25 at 7.39.48 PM.png,
> async.svg, classic.svg, contention.png, contention_defaultWAL.png
>
>
> Tests reveal that AsyncWAL under load in single node cluster performs slower
> than the Default WAL. This task is to analyze and see if we could fix it.
> See some discussions in the tail of JIRA HBASE-15536.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
