[
https://issues.apache.org/jira/browse/HBASE-20781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16522787#comment-16522787
]
stack commented on HBASE-20781:
-------------------------------
bq. IIRC the extra code which is used to construct the families for FSWALEntry
is introduced by per column family flush. I can remember it because I'm sure
that I also wanted to eliminate it in the first place but finally gave up.
Maybe the problem is in CP we can add or remove cells in WALEdit? Not sure,
long time ago...
Thanks [~Apache9]
You thinking we should keep this extra iteration? Should be fine if CPs add
edits for families already in the WALEdit. If they want to add edits for column
families not in current batch, they can update the WALEdit Set of families too?
Let me add a note. A note is not much by way of protection but I think better
to have CPs suffer than pay this CPU on each and every edit?
> Save recalculating families in a WALEdit batch of Cells
> -------------------------------------------------------
>
> Key: HBASE-20781
> URL: https://issues.apache.org/jira/browse/HBASE-20781
> Project: HBase
> Issue Type: Sub-task
> Components: Performance
> Reporter: stack
> Assignee: stack
> Priority: Major
> Attachments: 2.0621.2.12782.cpu.svg, 2.0621.256k.51351.cpu.svg,
> 2.0623.families.121250.cpu.svg, HBASE-20781.master.001.patch
>
>
> Doing a doMiniBatchMutate, we calculate the set of families that the WALEdit
> Cells belong to up front but down after the RingBuffer when we make an
> FSWALEdit, we spin through all the Cells again to figure the set of families
> in a particularly painful way. Just pass the calculated family set in the
> WALEdit.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
