[
https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15610784#comment-15610784
]
Duo Zhang commented on HBASE-16890:
-----------------------------------
Oh, sorry. The motivation is to reduce the locking time. I think the heaviest
operation when holding lock is offer and poll from queue, so I think we can use
a lock-free queue and move the offer and poll operations outside the lock. And
the ringbuffer sequence could also be used as txid.
But I'm not sure if it could perform better than ram's patch as here we still
have lots of threads that acquire the lock. In general, if the operation under
lock could be run very fast, then the synchronization will perform like a
spinlock which does not cause context switch.
Thanks.
> 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: AsyncWAL_disruptor.patch, 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)
