[
https://issues.apache.org/jira/browse/HBASE-16524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15781598#comment-15781598
]
stack commented on HBASE-16524:
-------------------------------
Lets commit. It is smarter tracking of the WAL files and a prerequisite for
what follows. I'm sure we'll get to know this code more intimately in the next
months.
> 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)
