edit on why bucketcache
Project: http://git-wip-us.apache.org/repos/asf/hbase/repo Commit: http://git-wip-us.apache.org/repos/asf/hbase/commit/1f1a676c Tree: http://git-wip-us.apache.org/repos/asf/hbase/tree/1f1a676c Diff: http://git-wip-us.apache.org/repos/asf/hbase/diff/1f1a676c Branch: refs/heads/master Commit: 1f1a676cfe5e132523b6bb9ac4a1f319b24656ff Parents: ef70ce8 Author: stack <[email protected]> Authored: Fri Aug 8 11:22:47 2014 -0700 Committer: stack <[email protected]> Committed: Mon Aug 18 14:13:33 2014 -0700 ---------------------------------------------------------------------- src/main/docbkx/book.xml | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/hbase/blob/1f1a676c/src/main/docbkx/book.xml ---------------------------------------------------------------------- diff --git a/src/main/docbkx/book.xml b/src/main/docbkx/book.xml index 11b356b..dbf9029 100644 --- a/src/main/docbkx/book.xml +++ b/src/main/docbkx/book.xml @@ -2113,9 +2113,11 @@ rs.close(); </para> <para>Fetching will always be slower when fetching from BucketCache, - as compared with the native onheap LruBlockCache. However, latencies tend to be - less erratic across time, because there is less garbage collection. This is why - you'd use BucketCache, so your latencies are less erratic and to mitigate GCs + as compared to the native onheap LruBlockCache. However, latencies tend to be + less erratic across time, because there is less garbage collection when you use + BucketCache since it is managing BlockCache allocations, not the GC. If the + BucketCache is deployed in offheap mode, this memory is not managed by the + GC at all. This is why you'd use BucketCache, so your latencies are less erratic and to mitigate GCs and heap fragmentation. See Nick Dimiduk's <link xlink:href="http://www.n10k.com/blog/blockcache-101/";>BlockCache 101</link> for comparisons running onheap vs offheap tests. Also see
