[
https://issues.apache.org/jira/browse/HBASE-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215085#comment-13215085
]
Prakash Khemani commented on HBASE-5347:
----------------------------------------
Lars, you are right. I have been trying to induce a Full GC but without
any success. (I can induce a full GC if I artificially hold some
key-values in queue and force them to be tenured.)
On 89-fb, my test-case is doing random increments on a space of slightly
more than 40GB worth of Key-value data. The heap is set to 36GB. The LRU
cache has a high and low watermark of .98 and .85 percents. The region
server spawns 1000 threads that continuously do the increments. The
eviction thread manages to keep the block-cache at about 85% always.
Cache-on-write is turned on to induce more cache churn. All the 12 disks
are close to 100% read pegged. GC takes 60% of the CPU (sum of user times
in 1000 lines of gc log / (elapsed time * #cpus)). Compactions that get
started never complete while the load is on.
I guess I have to change the dynamics of the test case to induce GC pauses.
On 2/22/12 11:35 PM, "Todd Lipcon (Commented) (JIRA)" <j...@apache.org>
wrote:
> GC free memory management in Level-1 Block Cache
> ------------------------------------------------
>
> Key: HBASE-5347
> URL: https://issues.apache.org/jira/browse/HBASE-5347
> Project: HBase
> Issue Type: Improvement
> Reporter: Prakash Khemani
> Assignee: Prakash Khemani
> Attachments: D1635.5.patch
>
>
> On eviction of a block from the block-cache, instead of waiting for the
> garbage collecter to reuse its memory, reuse the block right away.
> This will require us to keep reference counts on the HFile blocks. Once we
> have the reference counts in place we can do our own simple
> blocks-out-of-slab allocation for the block-cache.
> This will help us with
> * reducing gc pressure, especially in the old generation
> * making it possible to have non-java-heap memory backing the HFile blocks
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
