[
https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15607473#comment-15607473
]
ramkrishna.s.vasudevan commented on HBASE-16890:
------------------------------------------------
bq.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.
For doing the second one then it means we can't create a FSWALEntry till we do
the sync and we need to carry the edits upto the sync part.
The first one I think is doable. As I said since we don't go with disruptor we
need a sequence generator and since 'waitingConsumePayloads' acts as the
critical section for the consumer - we need to do a sync for getting unique
txids. Now may be we can add a disruptor and onEvent of the disruptor we can
hand over to the eventLoop?
But there is context switch here and one thread handing over to the other. I
can work on these two.
So we can first check the disruptor way or the append way?
Thanks Stack for your tests. Even myy JFR report had the contention issue but I
felt that sync and CRC update was *also* taking more time than the FSHLog
(classic) case.
> 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)
