河北建站公司,表白网站建设,怎么建网站数据库,给人做网站挣钱吗摘要#xff1a; GC一直是Java应用中讨论的一个热门话题#xff0c;尤其在像HBase这样的大型在线存储系统中#xff0c;大堆下(百GB)的GC停顿延迟产生的在线实时影响#xff0c;成为内核和应用开发者的一大痛点。 过去的一年里#xff0c;我们准备在Ali-HBase上突破这个被…摘要 GC一直是Java应用中讨论的一个热门话题尤其在像HBase这样的大型在线存储系统中大堆下(百GB)的GC停顿延迟产生的在线实时影响成为内核和应用开发者的一大痛点。 过去的一年里我们准备在Ali-HBase上突破这个被普遍认知的痛点为此进行了深度分析及全面创新的工作获得了一些比较好的效果。
福利国际顶级盛会HBaseCon Asia 2018将于8月在北京举行目前正免费开放申请中更多详情参考 https://yq.aliyun.com/promotion/631
如果你对大数据存储、分布式数据库、HBase等感兴趣欢迎加入我们一起做最好的大数据在线存储职位参考及联系方式https://maimai.cn/job?webjid1heZGIyM4srcu1aOrffoj1srcappfrmy_jobsrecruit_job
GC一直是Java应用中讨论的一个热门话题尤其在像HBase这样的大型在线存储系统中大堆下(百GB)的GC停顿延迟产生的在线实时影响成为内核和应用开发者的一大痛点。
过去的一年里我们准备在Ali-HBase上突破这个被普遍认知的痛点为此进行了深度分析及全面创新的工作获得了一些比较好的效果。以蚂蚁风控场景为例HBase的线上young GC时间从120ms减少到15ms结合阿里巴巴JDK团队提供的利器——ZenGC进一步在实验室压测环境做到了5ms。本文主要介绍我们过去在这方面的一些工作和技术思想。
背景
JVM的GC机制对开发者屏蔽了内存管理的细节提高了开发效率。说起GC很多人的第一反应可能是JVM长时间停顿或者FGC导致进程卡死不可服务的情况。但就HBase这样的大数据存储服务而言JVM带来的GC挑战相当复杂和艰难。原因有三:
1、内存规模巨大。线上HBase进程多数为96G大堆今年新机型已经上线部分160G以上的堆配置
2、对象状态复杂。HBase服务器内部会维护大量的读写cache达到数十GB的规模。HBase以表格的形式提供有序的服务数据数据以一定的结构组织起来这些数据结构产生了过亿级别的对象和引用
3、young GC频率高。访问压力越大young区的内存消耗越快部分繁忙的集群可以达到每秒1~2次youngGC 大的young区可以减少GC频率但是会带来更大的young GC停顿损害业务的实时性需求。
思路
HBase作为一个存储系统使用了大量的内存作为写buffer和读cache比如96G的大堆4G young 92G old下写buffer读cache会占用70%以上的内存(约70G本身堆内的内存水位会控制在85%而剩余的占用内存就只有在10G以内了。所以如果我们能在应用层面自管理好这70G的内存那么对于JVM而言百G大堆的GC压力就会等价于10G小堆的GC压力并且未来面对更大的堆也不会恶化膨胀。 在这个解决思路下我们线上的young GC时间获得了从120ms到15ms的优化效果。在一个高吞吐的数据密集型服务系统中大量的临时对象被频繁创建与回收如何能够针对性管理这些临时对象的分配与回收AliJDK团队研发了一种新的基于租户的GC算法—ZenGC。集团HBase基于这个新的ZenGC算法进行改造我们在实验室中压测的young GC时间从15ms减少到5ms这是一个未曾期望的极致效果。
下面将逐一介绍Ali-HBase版本GC优化所使用的关键技术。
消灭一亿个对象更快更省的CCSMap
目前HBase使用的存储模型是LSMTree模型写入的数据会在内存中暂存到一定规模后再dump到磁盘上形成文件。
下面我们将其简称为写缓存。写缓存是可查询的这就要求数据在内存中有序。为了提高并发读写效率并达成数据有序且支持seekscan的基本要求SkipList是使用得比较广泛的数据结构。 我们以JDK自带的ConcurrentSkipListMap为例子进行分析它有下面三个问题:
内部对象繁多。每存储一个元素平均需要4个对象(indexnodekeyvalue平均层高为1)新插入的对象在young区老对象在old区。当不断插入元素时内部的引用关系会频繁发生变化无论是ParNew算法的CardTable标记还是G1算法的RSet标记都有可能触发old区扫描。业务写入的KeyValue元素并不是规整长度的当它晋升到old区时可能产生大量的内存碎片。
问题1使得young区GC的对象扫描成本很高young GC时晋升对象更多。问题2使得young GC时需要扫描的old区域会扩大。问题3使得内存碎片化导致的FGC概率升高。当写入的元素较小时问题会变得更加严重。我们曾对线上的RegionServer进程进行统计活跃Objects有1亿2千万之多
分析完当前young GC的最大敌人后一个大胆的想法就产生了既然写缓存的分配访问销毁回收都是由我们来管理的如果让JVM“看不到”写缓存我们自己来管理写缓存的生命周期GC问题自然也就迎刃而解了。
说起让JVM“看不到”可能很多人想到的是off-heap的解决方案但是这对写缓存来说没那么简单因为即使把KeyValue放到offheap也无法避免问题1和问题2。而1和2也是young GC的最大困扰。
问题现在被转化成了如何不使用JVM对象来构建一个有序的支持并发访问的Map。 当然我们也不能接受性能损失因为写入Map的速度和HBase的写吞吐息息相关。 需求再次强化如何不使用对象来构建一个有序的支持并发访问的Map且不能有性能损失。
为了达成这个目标我们设计了这样一个数据结构
它使用连续的内存(堆内or堆外)我们通过代码控制内部结构而不是依赖于JVM的对象机制在逻辑上也是一个SkipList支持无锁的并发写入和查询控制指针和数据都存放在连续内存中上图所展示的即是CCSMap(CompactedConcurrentSkipListMap)的内存结构。 我们以大块的内存段(Chunk)的方式申请写缓存内存。每个Chunk包含多个Node每个Node对应一个元素。新插入的元素永远放在已使用内存的末尾。Node内部复杂的结构存放了Index/Next/Key/Value等维护信息和数据。新插入的元素需要拷贝到Node结构中。当HBase发生写缓存dump时整个CCSMap的所有Chunk都会被回收。当元素被删除时我们只是逻辑上把元素从链表里踢走不会把元素实际从内存中收回(当然做实际回收也是有方法就HBase而言没有那个必要)。
插入KeyValue数据时虽然多了一遍拷贝但是就绝大多数情况而言拷贝反而会更快。因为从CCSMap的结构来看一个Map中的元素的控制节点和KeyValue在内存上是邻近的利用CPU缓存的效率更高seek会更快。对于SkipList来说写速度其实是bound在seek速度上的实际拷贝产生的overhead远不如seek的开销。根据我们的测试CCSMap和JDK自带的ConcurrentSkipListMap相比50Byte长度KV的测试中读写吞吐提升了20~30%。
由于没有了JVM对象每个JVM对象至少占用16Byte空间也可以被节省掉(8byte为标记预留8byte为类型指针)。还是以50Byte长度KeyValue为例CCSMap和JDK自带的ConcurrentSkipListMap相比内存占用减少了40%。
CCSMap在生产中上线后实际优化效果 young GC从120ms减少到了30ms 优化前 优化后
使用了CCSMap后原来的1亿2千万个存活对象被缩减到了千万级别以内大大减轻了GC压力。由于紧致的内存排布写入吞吐能力也得到了30%的提升。
永不晋升的CacheBucketCache
HBase以Block的方式组织磁盘上的数据。一个典型的HBase Block大小在16K~64K之间。HBase内部会维护BlockCache来减少磁盘的I/O。BlockCache和写缓存一样不符合GC算法理论里的分代假说天生就是对GC算法不友好的 —— 既不稍纵即逝也不永久存活。
一段Block数据从磁盘被load到JVM内存中生命周期从分钟到月不等绝大部分Block都会进入old区只有Major GC时才会让它被JVM回收。它的麻烦主要体现在:
HBase Block的大小不是固定的且相对较大内存容易碎片化在ParNew算法上晋升麻烦。麻烦不是体现在拷贝代价上而是因为尺寸较大寻找合适的空间存放HBase Block的代价较高。
读缓存优化的思路则是向JVM申请一块永不归还的内存作为BlockCache我们自己对内存进行固定大小的分段当Block加载到内存中时我们将Block拷贝到分好段的区间内并标记为已使用。当这个Block不被需要时我们会标记该区间为可用可以重新存放新的Block这就是BucketCache。关于BucketCache中的内存空间分配与回收(这一块的设计与研发在多年前已完成)详细可以参考 : http://zjushch.iteye.com/blog/1751387 BucketCache
很多基于堆外内存的RPC框架也会自己管理堆外内存的分配和回收一般通过显式释放的方式进行内存回收。但是对HBase来说却有一些困难。我们将Block对象视为需要自管理的内存片段。Block可能被多个任务引用要解决Block的回收问题最简单的方式是将Block对每个任务copy到栈上(copy的block一般不会晋升到old区)转交给JVM管理就可以。
实际上我们之前一直使用的是这种方法实现简单JVM背书安全可靠。但这是有损耗的内存管理方式为了解决GC问题引入了每次请求的拷贝代价。由于拷贝到栈上需要支付额外的cpu拷贝成本和young区内存分配成本在cpu和总线越来越珍贵的今天这个代价显得高昂。
于是我们转而考虑使用引用计数的方式管理内存HBase上遇到的主要难点是:
HBase内部会有多个任务引用同一个Block同一个任务内可能有多个变量引用同一个Block。引用者可能是栈上临时变量也可能是堆上对象域。Block上的处理逻辑相对复杂Block会在多个函数和对象之间以参数、返回值、域赋值的方式传递。Block可能是受我们管理的也可能是不受我们管理的(某些Block需要手动释放某些不需要)。Block可能被转换为Block的子类型。
这几点综合起来对如何写出正确的代码是一个挑战。但在C 上使用智能指针来管理对象生命周期是很自然的事情为什么到了Java里会有困难呢
Java中变量的赋值在用户代码的层面上只会产生引用赋值的行为而C 中的变量赋值可以利用对象的构造器和析构器来干很多事情智能指针即基于此实现(当然C的构造器和析构器使用不当也会引发很多问题各有优劣这里不讨论)
于是我们参考了C的智能指针设计了一个Block引用管理和回收的框架ShrableHolder来抹平coding中各种if else的困难。它有以下的范式:
ShrableHolder可以管理有引用计数的对象也可以管理非引用计数的对象ShrableHolder在被重新赋值时释放之前的对象。如果是受管理的对象引用计数减1如果不是则无变化。ShrableHolder在任务结束或者代码段结束时必须被调用resetShrableHolder不可直接赋值。必须调用ShrableHolder提供的方法进行内容的传递因为ShrableHolder不可直接赋值需要传递包含生命周期语义的Block到函数中时ShrableHolder不能作为函数的参数。
根据这个范式写出来的代码原来的代码逻辑改动很少不会引入if else。虽然看上去仍然有一些复杂度所幸的是受此影响的区间还是局限于非常局部的下层对HBase而言还是可以接受的。为了保险起见避免内存泄漏我们在这套框架里加入了探测机制探测长时间不活动的引用发现之后会强制标记为删除。
将BucketCache应用之后减少了BlockCache的晋升开销减少了young GC时间 (CCSMapBucketCache优化后的效果)
追求极致ZenGC
经过以上两个大的优化之后蚂蚁风控生产环境的young GC时间已经缩减到15ms。由于ParNewCMS算法在这个尺度上再做优化已经很困难了我们转而投向ZenGC的怀抱。ZenGC在G1算法的基础上做了深度改进内存自管理的大堆HBase和ZenGC产生了很好的化学反应。
ZenGC是阿里巴巴JVM团队基于G1算法 面向大堆 (LargeHeap) 应用场景优化的GC算法的统称。这里主要介绍下多租户GC。
多租户GC包含的三层核心逻辑1 在JavaHeap上对象的分配按照租户隔离不同的租户使用不同的Heap区域2允许GC以更小的代价发生在租户粒度而不仅仅是应用的全局3允许上层应用根据业务需求对租户灵活映射。
ZenGC将内存Region划分为了多个租户每个租户内独立触发GC。在个基础上我们将内存分为普通租户和中等生命周期租户。中等生命周期对象指的是既不稍纵即逝也不永久存在的对象。由于经过以上两个大幅优化现在堆中等生命周期对象数量和内存占用已经很少了。但是中等生命周期对象在生成时会被old区对象引用每次young GC都需要扫描RSet现在仍然是young GC的耗时大头。
借助于AJDK团队的ObjectTrace功能我们找出中等生命周期对象中最大头的部分将这些对象在生成时直接分配到中等生命周期租户的old区避免RSet标记。而普通租户则以正常的方式进行内存分配。
普通租户GC频率很高但是由于晋升的对象少跨代引用少Young区的GC时间得到了很好的控制。在实验室场景仿真环境中我们将young GC优化到了5ms。 (ZenGC优化后的效果单位问题此处为us) 云端使用
阿里HBase目前已经在阿里云提供商业化服务任何有需求的用户都可以在阿里云端使用深入改进的、一站式的HBase服务。云HBase版本与自建HBase相比在运维、可靠性、性能、稳定性、安全、成本等方面均有很多的改进更多内容欢迎大家关注 https://www.aliyun.com/product/hbase
写在最后
如果你对大数据存储、分布式数据库、HBase等感兴趣欢迎加入我们一起做最好的大数据在线存储职位参考及联系方式https://maimai.cn/job?webjid1heZGIyM4srcu1aOrffoj1srcappfrmy_jobsrecruit_job
原文链接
