[
https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15154494#comment-15154494
]
stack commented on HBASE-15205:
-------------------------------
bq. So once we pass the replication scope we need to nullify it based on the
logEdit.
Can you point me at where this is happening? We are setting scopes into a
WALKey on write. We then null out the scopes on read from the WAL?
I'm not on all the contexts. Pardon me. What seems crazy to me is having scopes
in WALEdit AND in the WALKey. Our WALEdit is already super fat with some
dup'd/redundant info when it should be super slim since it is what makes the
hbase world go around. This is where I am coming from. Thanks.
> Do not find the replication scope for every WAL#append()
> --------------------------------------------------------
>
> Key: HBASE-15205
> URL: https://issues.apache.org/jira/browse/HBASE-15205
> Project: HBase
> Issue Type: Sub-task
> Components: regionserver
> Reporter: ramkrishna.s.vasudevan
> Assignee: ramkrishna.s.vasudevan
> Priority: Minor
> Fix For: 2.0.0
>
> Attachments: HBASE-15204_6.patch, HBASE-15205.patch,
> HBASE-15205_1.patch, HBASE-15205_2.patch, HBASE-15205_3.patch,
> HBASE-15205_4.patch, ScopeWALEdits.jpg, ScopeWALEdits_afterpatch.jpg
>
>
> After the byte[] and char[] the other top contributor for lot of GC (though
> it is only 2.86%) is the UTF_8.newDecoder.
> This happens because for every WAL append we try to calculate the replication
> scope associate with the families associated with the TableDescriptor. I
> think per WAL append doing this is very costly and creates lot of garbage.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
