You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bookkeeper.apache.org by "Ivan Kelly (JIRA)" <ji...@apache.org> on 2012/12/04 19:52:58 UTC

[jira] [Commented] (BOOKKEEPER-451) Reorder writes based on ledger-id before writing to the log file

    [ https://issues.apache.org/jira/browse/BOOKKEEPER-451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509941#comment-13509941 ] 

Ivan Kelly commented on BOOKKEEPER-451:
---------------------------------------

I made an attempt at this over the weekend, as Yixue had said somewhere that the performance you got with this approach wasn't good. The attached patch is just a proof of concept, and not meant to go in, but there's some interesting things in it which could be incorporated into BOOKKEEPER-432. Such as:

# It makes very few changes to the existing code, and I think that all of them are unnecessary.
# The real bottleneck on write is LedgerCache#flushLedgers(). As such, we should put only this in the flushThread, and flush the entryLogger in another thread. I don't write any offsets to the ledger cache until they've been written to the entrylog and flushed. Writes to the idx files can continue in the background, while the actually flush is running. I think this allows the disk to schedule writes better. This has the nice advantage of fixing BOOKKEEPER-447 in the process.
# The output files are 100% backward compatible.

Now, getting to performance. For reads, this blows InterleavedLedgerStorage out of the water for reading 1 ledger of 1000 written. They level out as you read more. InterleavedLedgerStorage starts winning when reading 400 of 1000 ledgers. This is due to the fact that there is no cooperation in the reads, which could be fixed by using an elevator algorithm in the read path. 

!readPerf.png!

For write performance, we actually beat InterleavedLedgerStorage up until 10000, which im guessing is due to higher contention on the slabs. 

!writePerf.png!

An important thing to remember also, is I haven't tuned this at all. The number of slabs and their size are values pulled out of thin air. I think with a bit of tuning this could beat InterleavedLedgerStorage on all fronts. In any case, this and BOOKKEEPER-432 is work for after 4.2.0 is out.
                
> Reorder writes based on ledger-id before writing to the log file
> ----------------------------------------------------------------
>
>                 Key: BOOKKEEPER-451
>                 URL: https://issues.apache.org/jira/browse/BOOKKEEPER-451
>             Project: Bookkeeper
>          Issue Type: Bug
>          Components: bookkeeper-server
>    Affects Versions: 4.2.0
>            Reporter: Aniruddha
>            Assignee: Aniruddha
>             Fix For: 4.3.0
>
>         Attachments: 0001-Slab-allocator.patch, readPerf.png, writePerf.png
>
>
> Allocate chunks to ledgers on writes to the log file to improve entry locality per ledger.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira