[ 
https://issues.apache.org/jira/browse/HBASE-15205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15138363#comment-15138363
 ] 

ramkrishna.s.vasudevan edited comment on HBASE-15205 at 2/9/16 8:34 AM:
------------------------------------------------------------------------

bq.When then is the scope checked? When we go to replicate after reading the 
WAL? We'd be trading CPU for i/o?
Actually in the current code we check the scope both on writes and reads. So 
when we try to replicate we once again try to iterate the scope that was 
persisted and check against the families associated with every cell and only 
then decide on which one to be replicated. 
bq.We'd be trading CPU for i/o?
Yes but on the write path only. But now if we make this change may be more data 
is written per WAL Key for a multiCF case. 


was (Author: ram_krish):
bq.When then is the scope checked? When we go to replicate after reading the 
WAL? We'd be trading CPU for i/o?
Actually in the current code we check the scope both on writes and reads. So 
when we try to replicate we once again try to iterate the scope that was 
persisted and check against the families associated with every cell and only 
then decide on which one to be replicated. 
bq.We'd be trading CPU for i/o?
Yes but on the write path only. But now may be more data is written per WAL Key 
for a multiCF case. 

> 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-15205.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)

Reply via email to