[
https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15156487#comment-15156487
]
ramkrishna.s.vasudevan commented on HBASE-15205:
------------------------------------------------
bq.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?
The below is in FSHLog#append()
{code}
if (!coprocessorHost.preWALWrite(entry.getHRegionInfo(), entry.getKey(),
entry.getEdit())) {
if (entry.getEdit().isReplay()) {
// Set replication scope null so that this won't be replicated
entry.getKey().setScopes(null);
}
}
{code}
The below is in WALSplitter.
{code}
TableName table = entry.getKey().getTablename();
// clear scopes which isn't needed for recovery
entry.getKey().setScopes(null);
{code}
So if I directly pass the scope to WALKey every time during its constrution
then we may have to nullify it where ever it applies.
Below from Replication#scopeWalEdits()
{code}
if (!scopes.isEmpty()) {
logKey.setScopes(scopes);
}
{code}
Even here after we do want to make it work as per in current patch some times
we may not need the scope to be applied per WALKey some times like in case of
BulkLoad WALReplication. So every time setting scope to WALKey may want us to
nullify later based on condition.
I really understand your concern and it makes sense. Let me see what else can
be done but I thought that wil deviate from the scope of the JIRA in case if we
want to make things lighter for the WALEdit and WALKey.
> 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)
