在Hypertable系统的运维中，我们发现，Hypertable在内存使用效率上存在严重问题。在数据插入过程中，Range Server内存用量一直飙升，而且持久不下，很容易造成内存溢出并最终崩溃，严重威胁Hypertable的稳定性。

    为了定位内存占用过量问题，我们使用valgrind和TCMalloc库的Heap Profiling工具对Hypertable进行了测试，发现Hypertable内存飙升的原因是Cell Cache代码中存在频繁分配、释放小片内存（从十几字节到几千字节不等）的情况，从而产生了大量内存碎片，致使内存效率存在严重问题。如图4所示，Range Server中的大量内存分配集中于Cell Cache为<key, value>和Cell Map进行空间分配的时候。
 

    图4 改进前Range Server内存使用情况统计

    解决：我们决定对Cell Cache相关的内存实施独立管理，即采用自定义的内存分配回收方式管理<key, value>和Cell Map,使其产生的内存碎片最小化。

    图5显示了Hypertable数据服务器上的数据更新过程。Client向Range Server发送数据（<key, value>形式），Range Server首先将数据缓存在Cell Cache中，并使用Cell Map结构建立树形索引。当需要进行Compaction时，会新开一个Cell Cache,并把当前Cell Cache冻结，新写入的数据会进入新开的Cell Cache,而冻结的Cell Cache则在后台写到文件系统中形成Cell Store文件，Compaction完成后，冻结了的Cell Cache会被统一释放。此过程中，Cell Cache涉及的内存分配释放操作主要有：分配空间（new）容纳要写入的key/value;分配空间维护Cell Map（本质上是一个std::map,使用默认的STL allocator分配空间）索引结构；释放数据和索引占用的全部空间。可见，问题主要出在内存分配太过细碎。
 

    图5 Hypertable插入数据时Cell Cache内存分配示意图

    我们修改了Cell Cache的分配策略，利用简化的内存池思想，将内存分配策略改为统一分配。每个Cell Cache使用1个内存池（MemPool），每个MemPool初始时包含1个4MB（默认设置）的缓冲区（MemBuf），所有的<key, value>和Cell Map结构占用的空间都在MemBuf内部分配。当MemBuf满了之后，再分配一片新的MemBuf,释放时也是大片释放，这样就防止了频繁的new/delete操作。此外，<key, value>和Cell Map结构占用的内存是分别从MemBuf的两端分配的，这样做的目的是保证Cell Map内存对齐，减少因为内存非对齐访问带来的效率下降。当一个缓冲区用满后，内存池会自动扩充一个新的缓冲区，内存释放只是针对整个内存池。

    这种内存池分配方式最终也被合入到Hypertable官方版本之中。

    图6给出了Google Heap Profiling工具检测的Cell Cache内存使用情况，对比图4中的数据，改进后版本Range Server的主要内存使用集中于CellCachePool::get_memory,即Cell Cache的内存使用，这和原始版本中主要使用内存的地方是一致的。这说明如果我们的内存管理机制有效，就能大量减小Hypertable的内存占用量。
 

    图6 改进后Range Server内存使用情况统计

    图7给出了Range Server的Cell Cache在使用普通new/delete、TC Malloc、Pool Malloc（with Map）以及Pool Malloc（without Map）四种内存分配方式下，插入数据过程及之后的内存占用量对比。图7中的蓝、绿、黄、红四种颜色分别对应上述的四种分配方式。可以看出，普通分配方式的内存占用量最不理想，并且最终不能降低，最终内存占用约6.4GB;TC Malloc方式较前者略好，内存占用增长方式也与之相似，也是最终内存占用很大，约4.4GB;后两种内存池方式在整个过程中的内存占用变化趋势很一致，区别在于对Cell Map使用内存池分配方式的曲线最终能够降到很低（30MB左右），而对Map使用默认（STL库）内存分配方式的曲线下降的幅度并没有那么大，最终的内存占用大约为929MB.
 

    图7 各种分配策略下的Range Server内存使用情况对比



 

优化Hypertable系统随机性能 图

Hypertable的安全停机策略

Hypertable的分裂日志策略

Hypertable集群故障处理

Hypertable高可用改进架构 图

Hypertable与HBase业务应用比对 图
 

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。