You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@hbase.apache.org by "stack (JIRA)" <ji...@apache.org> on 2016/12/27 21:55:58 UTC

[jira] [Commented] (HBASE-16524) Procedure v2 - Compute WALs cleanup on wal modification and not on every sync

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

stack commented on HBASE-16524:
-------------------------------

I pushed a rebased patch.

> Procedure v2 - Compute WALs cleanup on wal modification and not on every sync
> -----------------------------------------------------------------------------
>
>                 Key: HBASE-16524
>                 URL: https://issues.apache.org/jira/browse/HBASE-16524
>             Project: HBase
>          Issue Type: Sub-task
>          Components: proc-v2
>    Affects Versions: 2.0.0
>            Reporter: Appy
>            Assignee: Matteo Bertozzi
>            Priority: Minor
>             Fix For: 2.0.0
>
>         Attachments: HBASE-16524-v2.patch, HBASE-16524-v3.patch, HBASE-16524-v4.patch, HBASE-16524-v5.patch, HBASE-16524-v6.patch, HBASE-16524.master.001.patch, HBASE-16524.master.002.patch, flame1.svg
>
>
> Fix performance regression introduced by HBASE-16094.
> Instead of scanning all the wals every time, we can rely on the insert/update/delete events we have.
> and since we want to delete the wals in order we can keep track of what is "holding" that wal, and take a hit on scanning all the trackers only when we remove the first log in the queue.
> e.g.
> WAL-1 [1, 2] 
> WAL-2 [1] -> "[2] is holding WAL-1"
> WAL-3 [2] -> "WAL 1 can be removed, recompute what is holding WAL-2"



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)