[
https://issues.apache.org/jira/browse/HBASE-20806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16526599#comment-16526599
]
Andrew Purtell edited comment on HBASE-20806 at 6/28/18 5:47 PM:
-----------------------------------------------------------------
bq. Are you targeting 1.x or 2.0 for this work ?
Are we now contemplating commits only to branch-1? I guess for components like
the AM that have significantly diverged it could happen, but generally we
should assume contributions proceed via the standard path: trunk -> branch-2 ->
branch-1 -> release branches.
bq. Thinking of modifying taskmonitor such that we maintain a journal of
various status (that we already set in flushes/compactions etc.) and then
finally logging it when we complete flush/compaction.
Big +1 to the approach. We need to see where time is going in flushes and
compactions to get insight into performance regressions from 0.98 we are
seeing. Note also flushes are 2x slower in 2.0 so that branch can benefit from
this data for the separate investigation there (/cc [~stack]). As the
contributor of the split journal transaction let me say simply recording a
timestamp as actions are taken is very simple, low impact, and can really help
a performance investigation.
was (Author: apurtell):
bq. Are you targeting 1.x or 2.0 for this work ?
Are we now contemplating commits only to branch-1? I guess for components like
the AM that have significantly diverged it could happen, but generally we
should assume contributions proceed via the standard path: trunk -> branch-2 ->
branch-1 -> release branches.
Big +1 to the approach. We need to see where time is going in flushes and
compactions to get insight into performance regressions from 0.98 we are
seeing. Note also flushes are 2x slower in 2.0 so that branch can benefit from
this data for the separate investigation there (/cc [~stack]). As the
contributor of the split journal transaction let me say simply recording a
timestamp as actions are taken is very simple, low impact, and can really help
a performance investigation.
> Split style journal for flushes and compactions
> -----------------------------------------------
>
> Key: HBASE-20806
> URL: https://issues.apache.org/jira/browse/HBASE-20806
> Project: HBase
> Issue Type: Improvement
> Reporter: Abhishek Singh Chouhan
> Assignee: Abhishek Singh Chouhan
> Priority: Minor
>
> In 1.x we have split transaction journal that gives a clear picture of when
> various stages of splits took place. We should have a similar thing for
> flushes and compactions so as to have insights into time spent in various
> stages, which we can use to identify regressions that might creep up.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
