[
https://issues.apache.org/jira/browse/HBASE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708760#action_12708760
]
stack commented on HBASE-1008:
------------------------------
J-D, what you think of suggestion over here:
https://issues.apache.org/jira/browse/HBASE-1394?focusedCommentId=12708663&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12708663?
I'm not going to bother with pool of writers for 0.20.0 -- logging is back to
fast enough and besides, looks like we could do with some friction since its so
easy overrunning compactions -- but the bit where we add timestamp to HLogKey
and we then run multiple threads in master splitting up the N logs, hows that
sounds? Could cut recover in 3 or 4 or ten even if we ran ten concurrent
splitter threads in master?
> [performance] The replay of logs on server crash takes way too long
> -------------------------------------------------------------------
>
> Key: HBASE-1008
> URL: https://issues.apache.org/jira/browse/HBASE-1008
> Project: Hadoop HBase
> Issue Type: Improvement
> Reporter: stack
> Assignee: Jean-Daniel Cryans
> Priority: Blocker
> Fix For: 0.20.0
>
> Attachments: 1008-v2.patch, hbase-1008-3.patch
>
>
> Watching recovery from a crash on streamy.com where there were 1048 logs and
> repay is running at rate of about 20 seconds each. Meantime these regions
> are not online. This is way too long to wait on recovery for a live site.
> Marking critical. Performance related so priority and in 0.20.0.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
