[
https://issues.apache.org/jira/browse/HBASE-15536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585269#comment-15585269
]
ramkrishna.s.vasudevan commented on HBASE-15536:
------------------------------------------------
As said, we are doing some experiments to check how we can run with AsyncWAL
when we have the write path in offheap structures. This JIRA creates an
outputStream which allows to work with ByteBuffers.
But overall we see a significant degrade just in using the current trunk with
ASYNC_WAL and default_WAL.
With PE tool with 10 cols and 50 threads
With Default WAL
============
2185.113s
With Async WAL
============
3758.702s
Since this is a single node system the load on the DN and NN is heavy and so
the msg
bq.Slow sync cost: 166 ms, current pipeline:
[DatanodeInfoWithStorage[10.224.54.65:18223,DS-bc84f329-2043-4891-b878-f368c774b246,DISK]]
The thread model between the default case and the ASYNC WALbasically tries to
be the same. We have some contentions with the ArrayDeque that is in AsyncWAL
now.
But the major difference I could see is that in the default WAL case the
checksum is being done in the append() flow because append() adds the data to
the FSDataOS.
In the AsyncWAL we add the data to the new BAOS but it is the sync call that
actually does the check summing.
Interesting thing is that when we run the WALPE tool with 50 threads with key
size 50 : val : 200 , AsyncWAL is performing better in terms of ops/sec.
Default WAL
{code}
Summary: threads=50, iterations=1000000, syncInterval=0 took 1475.368s
33889.848ops/s
{code}
AsyncWAL
{code}
Summary: threads=50, iterations=1000000, syncInterval=0 took 1368.501s
36536.328ops/s
{code}
> Make AsyncFSWAL as our default WAL
> ----------------------------------
>
> Key: HBASE-15536
> URL: https://issues.apache.org/jira/browse/HBASE-15536
> Project: HBase
> Issue Type: Sub-task
> Components: wal
> Affects Versions: 2.0.0
> Reporter: Duo Zhang
> Assignee: Duo Zhang
> Priority: Critical
> Fix For: 2.0.0
>
> Attachments: HBASE-15536-v1.patch, HBASE-15536-v2.patch,
> HBASE-15536-v3.patch, HBASE-15536-v4.patch, HBASE-15536-v5.patch,
> HBASE-15536.patch
>
>
> As it should be predicated on passing basic cluster ITBLL
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)