[
https://issues.apache.org/jira/browse/HBASE-16890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15601494#comment-15601494
]
ramkrishna.s.vasudevan commented on HBASE-16890:
------------------------------------------------
[~saint....@gmail.com]
Can you try with more columns?
I just did this
{code}
./hbase org.apache.hadoop.hbase.wal.WALPerformanceEvaluation -threads 50
-iterations 1000000 -qualifiers 10 -keySize 50 -valueSize 200
{code}
and more or less I got same ops/sec with Async and default.
So my doubt is this -
In the default case every Append call was triggered and the FSDataOutputStream
was doing the checkSum after summer.getBytesPerCheckSum was filled up. So the
CPU time spent in summer#calculateChunkedSums() is lesser but the number of
times this getting called is more but in the AsyncWAL case every sync is
performed on we do the checksum on the entire data and so the CPU time spent
there is siginifcantly more?
> 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)
