[
https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15606785#comment-15606785
]
stack commented on HBASE-16890:
-------------------------------
The disruptor consumer thread would feed the eventloop? Could. Another thought
was just collect the appends and not assign the trans id until we are going to
sync since that is when we add the edit to the WAL and given that the write
path is different in master -- we don't update memstore until after sync has
come home -- then this could work.
One node is bringing out the fact that asyncfswal currently does not run as
free as dfsclient#dfsos and the latter is friction-full with its
packet-stutter. You've made it so it is easy to work on this now. No rush --
asyncwal is better than dfsclient in a couple of regards -- but yeah, lets make
it so asyncwal blows away dfsclient any way you look at it.
> 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: 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)
