[
https://issues.apache.org/jira/browse/HBASE-8755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13832233#comment-13832233
]
Feng Honghua commented on HBASE-8755:
-------------------------------------
tried 4 asyncSyncer threads, below are the results. a bit worse than 5 threads
but looks like acceptable?
||threads||ops-wo-patch||ops-w-patch||ops-diff||
|1|1716|1572|-8.4%|
|3|3179|3189|+0.3%|
|5|6091|5593|-8.1%|
|10|8760|9450|+7.8%|
|25|13019|18055|+38.7%|
|50|14995|26597|+77.3%|
|100|18824|51441|+173.2%|
|200|18144|61531|+239.1%|
additional explanation on correctness when introducing extra asyncSyncer
threads:
- when a txid(t0) is notified, all txid smaller than t0 must already be written
to hdfs and by sync-ed: before t0 is notified, t0 must be sync-ed by an
asyncSyncer thread; before t0 is sync-ed, t0 must be written to hdfs by
asyncWriter thread; before t0 is written to hdfs, all txid smaller than t0 must
be written to hdfs, so the sync of t0 can guarantee all txid smaller than t0
must be sync-ed (either before the sync of t0, or by the sync of t0)
- when a txid(t0) can't find free(idle) asyncSyncer thread and added to a
random one, it won't be sync-ed until its asyncSyncer thread is done with the
txid at hand. but its entries already have been written to hdfs, and if any
bigger txid than t0 (say t1) is successfully sync-ed by another parallel
asyncSyncer thread, that sync can guarantee t0 also successfully sync-ed, hence
when t1 is notified, t0 can also be correctly notified.
any further comments?
> A new write thread model for HLog to improve the overall HBase write
> throughput
> -------------------------------------------------------------------------------
>
> Key: HBASE-8755
> URL: https://issues.apache.org/jira/browse/HBASE-8755
> Project: HBase
> Issue Type: Improvement
> Components: Performance, wal
> Reporter: Feng Honghua
> Assignee: stack
> Priority: Critical
> Attachments: 8755trunkV2.txt, HBASE-8755-0.94-V0.patch,
> HBASE-8755-0.94-V1.patch, HBASE-8755-0.96-v0.patch,
> HBASE-8755-trunk-V0.patch, HBASE-8755-trunk-V1.patch,
> HBASE-8755-trunk-v4.patch
>
>
> In current write model, each write handler thread (executing put()) will
> individually go through a full 'append (hlog local buffer) => HLog writer
> append (write to hdfs) => HLog writer sync (sync hdfs)' cycle for each write,
> which incurs heavy race condition on updateLock and flushLock.
> The only optimization where checking if current syncTillHere > txid in
> expectation for other thread help write/sync its own txid to hdfs and
> omitting the write/sync actually help much less than expectation.
> Three of my colleagues(Ye Hangjun / Wu Zesheng / Zhang Peng) at Xiaomi
> proposed a new write thread model for writing hdfs sequence file and the
> prototype implementation shows a 4X improvement for throughput (from 17000 to
> 70000+).
> I apply this new write thread model in HLog and the performance test in our
> test cluster shows about 3X throughput improvement (from 12150 to 31520 for 1
> RS, from 22000 to 70000 for 5 RS), the 1 RS write throughput (1K row-size)
> even beats the one of BigTable (Precolator published in 2011 says Bigtable's
> write throughput then is 31002). I can provide the detailed performance test
> results if anyone is interested.
> The change for new write thread model is as below:
> 1> All put handler threads append the edits to HLog's local pending buffer;
> (it notifies AsyncWriter thread that there is new edits in local buffer)
> 2> All put handler threads wait in HLog.syncer() function for underlying
> threads to finish the sync that contains its txid;
> 3> An single AsyncWriter thread is responsible for retrieve all the buffered
> edits in HLog's local pending buffer and write to the hdfs
> (hlog.writer.append); (it notifies AsyncFlusher thread that there is new
> writes to hdfs that needs a sync)
> 4> An single AsyncFlusher thread is responsible for issuing a sync to hdfs
> to persist the writes by AsyncWriter; (it notifies the AsyncNotifier thread
> that sync watermark increases)
> 5> An single AsyncNotifier thread is responsible for notifying all pending
> put handler threads which are waiting in the HLog.syncer() function
> 6> No LogSyncer thread any more (since there is always
> AsyncWriter/AsyncFlusher threads do the same job it does)
--
This message was sent by Atlassian JIRA
(v6.1#6144)
