[
https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15632004#comment-15632004
]
ramkrishna.s.vasudevan commented on HBASE-16890:
------------------------------------------------
bq. I think there is a logic error.
Ya. That is true. I just saw that. But in WALPE anyway we don't use sync(txid)
and we use sync(). So I am not sure if it is really affecting the result of
WALPE. But yes may be in cluster it can affect and we may not wait for some
sync completion and return early. I will test that.
Also in the patch
{code}
if (highestSyncedTxid.get() >= txid) {
return;
}
{code}
I need to unify both sync() and sync(txid) and I cannot have the above there if
am not using the RingBuffer's sequence.
Just WALPE with existing AsyncFSWAL I get this
{code}
Summary: threads=100, iterations=25000, syncInterval=0 took 106.369s
23503.088ops/s
{code}
> 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, AsyncWAL_disruptor_1
> (2).patch, AsyncWAL_disruptor_3.patch, AsyncWAL_disruptor_3.patch,
> HBASE-16890-remove-contention-v1.patch, HBASE-16890-remove-contention.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)
