[ 
https://issues.apache.org/jira/browse/HBASE-16650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anoop Sam John updated HBASE-16650:
-----------------------------------
    Description: 
1. We use the stat evictedBlocksCount - A block can get evicted because of 
eviction thread due to lack of space or because of removal of an HFile itself 
(After a compaction). We should not consider the latter in the tune decision at 
all. These are actually invalidation of blocks. Should the stat counter itself 
not use this count of evicted blocks? I think yes. This will give wrong message 
to users that there are lot of real eviction happening.
2. In case L1+ L2 combined block cache, what we use is the sum of evictions 
from both. But we will be tuning L1 size alone. Eviction count from L2 should 
not affect the tuning of L1

> Wrong usage of BlockCache eviction stat for heap memory tuning
> --------------------------------------------------------------
>
>                 Key: HBASE-16650
>                 URL: https://issues.apache.org/jira/browse/HBASE-16650
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Anoop Sam John
>            Assignee: Anoop Sam John
>             Fix For: 2.0.0
>
>
> 1. We use the stat evictedBlocksCount - A block can get evicted because of 
> eviction thread due to lack of space or because of removal of an HFile itself 
> (After a compaction). We should not consider the latter in the tune decision 
> at all. These are actually invalidation of blocks. Should the stat counter 
> itself not use this count of evicted blocks? I think yes. This will give 
> wrong message to users that there are lot of real eviction happening.
> 2. In case L1+ L2 combined block cache, what we use is the sum of evictions 
> from both. But we will be tuning L1 size alone. Eviction count from L2 should 
> not affect the tuning of L1



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to