HBase GC的前生今世 – 演进篇

最原始的HBase CMS GC相当严重,经常会因为碎片过多导致Promotion Failure,严重影响业务的读写请求。幸运的是,HBase并没有止步不前,很多优化方案相继被提出并贡献给社区,本文要介绍的就是几个比较重要的核心优化,分别是针对Memstore所作的两个优化:Thread-Local Allocation Buffer和MemStore Chunk Pool 以及针对BlockCache所作的优化:BucketCache方案。在详细介绍这几个优化之前有必要简单介绍一下HBase GC优化的目标,很直观的,第一是要尽量避免长时间的Full GC,避免影响用户的读写请求;第二是尽量减少GC时间,提高读写性能;接着分别来看HBase针对GC所做的各种优化

MemStore GC优化一 - Thread-Local Allocation Buffe

HBase数据写入操作实际上并...

继续阅读

HBase GC的前生今世 – 身世篇

在之前的HBase BlockCache系列文章中已经简单提到:使用LRUBlockCache缓存机制会因为CMS GC策略导致内存碎片过多,从而可能引发臭名昭著的Full GC,触发可怕的'stop-the-world'暂停,严重影响上层业务;而Bucket Cache缓存机制因为在初始化的时候就申请了一片固定大小的内存作为缓存,缓存淘汰不再由 JVM管理,数据Block的缓存操作只是对这篇空间的访问和覆盖,因而大大减少了内存碎片的出现,降低了Full GC发生的频率。那CMS GC策略如何导致内存碎片过多?内存碎片过多如何触发Full GC?HBase在演进的道路上又如何不断优化CMS GC?接下来这个系列《HBase GC的前生今生》将会为你一一揭开谜底,这个系列一共两篇文章,本篇文章-’身世篇’将会带你全面了解HBase的GC机制,后面一篇-’演进篇’将会给你道出HBase在发展的...

继续阅读

HBase BlockCache系列 - 性能对比测试报告

HBase BlockCache系列文章到了终结篇,几个主角的是是非非也该有个了断了,在SlabCache被早早地淘汰之后,站在华山之巅的也就仅剩LRU君(LRUBlockCache)和CBC君(CombinedBlockCache)。谁赢谁输,我说了不算,你说了也不算,那就来让数据说话。这篇文章主要对比LRU君和CBC君(offheap模式)分别在四种场景下几种指标(GC、Throughput、Latency、CPU、IO等)的表现情况。四种场景分别是缓存全部命中、少大部分缓存命中、少量缓存命中、缓存基本未命中。

需要注意的是,本文的所有数据都来自社区文档,在这里分享也只是给大家一个参考,更加详细的测试数据可以阅读文章《Comparing BlockCache DeploysHBASE-1132附件报告。

说明:本文所有图都以时间为横坐标,纵坐标为对应指标。每张图都会分别显示LRU君和...

继续阅读