过去的一年里, 我们准备在 Ali-HBase 上突破这个被普遍认知的痛点, 为此进行了深度分析及全面创新的工作, 获得了一些比较好的效果以蚂蚁风控场景为例, HBase 的线上 young GC 时间从 120ms 减少到 15ms, 结合阿里巴巴 JDK 团队提供的利器 AliGC, 进一步在实验室压测环境做到了 5ms 本文主要介绍我们过去在这方面的一些工作和技术思想
背景
JVM 的 GC 机制对开发者屏蔽了内存管理的细节, 提高了开发效率说起 GC, 很多人的第一反应可能是 JVM 长时间停顿或者 FGC 导致进程卡死不可服务的情况但就 HBase 这样的大数据存储服务而言, JVM 带来的 GC 挑战相当复杂和艰难原因有三:
1 内存规模巨大线上 HBase 进程多数为 96G 大堆, 今年新机型已经上线部分 160G 以上的堆配置
2 对象状态复杂 HBase 服务器内部会维护大量的读写 cache, 达到数十 GB 的规模 HBase 以表格的形式提供有序的服务数据, 数据以一定的结构组织起来, 这些数据结构产生了过亿级别的对象和引用
3young GC 频率高访问压力越大, young 区的内存消耗越快, 部分繁忙的集群可以达到每秒 1~2 次 youngGC, 大的 young 区可以减少 GC 频率, 但是会带来更大的 young GC 停顿, 损害业务的实时性需求
思路
1. HBase 作为一个存储系统, 使用了大量的内存作为写 buffer 和读 cache, 比如 96G 的大堆 (4G young + 92G old) 下, 写 buffer + 读 cache 会占用 70% 以上的内存(约 70G), 本身堆内的内存水位会控制在 85%, 而剩余的占用内存就只有在 10G 以内了所以, 如果我们能在应用层面自管理好这 70G + 的内存, 那么对于 JVM 而言, 百 G 大堆的 GC 压力就会等价于 10G 小堆的 GC 压力, 并且未来面对更大的堆也不会恶化膨胀 在这个解决思路下, 我们线上的 young GC 时间获得了从 120ms 到 15ms 的优化效果
2. 在一个高吞吐的数据密集型服务系统中, 大量的临时对象被频繁创建与回收, 如何能够针对性管理这些临时对象的分配与回收, AliJDK 团队研发了一种新的基于租户的 GC 算法 AliGC 集团 HBase 基于这个新的 AliGC 算法进行改造, 我们在实验室中压测的 young GC 时间从 15ms 减少到 5ms, 这是一个未曾期望的极致效果
下面将逐一介绍 Ali-HBase 版本 GC 优化所使用的关键技术
消灭一亿个对象: 更快更省的 CCSMap
目前 HBase 使用的存储模型是 LSMTree 模型, 写入的数据会在内存中暂存到一定规模后再 dump 到磁盘上形成文件
下面我们将其简称为写缓存写缓存是可查询的, 这就要求数据在内存中有序为了提高并发读写效率, 并达成数据有序且支持 seek&scan 的基本要求, SkipList 是使用得比较广泛的数据结构
58f76b7ba750e50270ef32dd46824307a5d3645b
我们以 JDK 自带的 ConcurrentSkipListMap 为例子进行分析, 它有下面三个问题:
1. 内部对象繁多每存储一个元素, 平均需要 4 个对象(index+node+key+value, 平均层高为 1)
2. 新插入的对象在 young 区, 老对象在 old 区当不断插入元素时, 内部的引用关系会频繁发生变化, 无论是 ParNew 算法的 CardTable 标记, 还是 G1 算法的 RSet 标记, 都有可能触发 old 区扫描
3. 业务写入的 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, 支持无锁的并发写入和查询
控制指针和数据都存放在连续内存中
ca814f49b62436a12186d01fd39a285c32fa86ef
上图所展示的即是 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
ae9cd66c2bd2f434820907ab924260deba709d58
优化前
103ee25343ec5a45342a12d3fc7478005bf2ff72
优化后
使用了 CCSMap 后, 原来的 1 亿 2 千万个存活对象被缩减到了千万级别以内, 大大减轻了 GC 压力由于紧致的内存排布, 写入吞吐能力也得到了 30% 的提升
永不晋升的 Cache:BucketCache
HBase 以 Block 的方式组织磁盘上的数据一个典型的 HBase Block 大小在 16K~64K 之间 HBase 内部会维护 BlockCache 来减少磁盘的 I/OBlockCache 和写缓存一样, 不符合 GC 算法理论里的分代假说, 天生就是对 GC 算法不友好的 既不稍纵即逝, 也不永久存活
一段 Block 数据从磁盘被 load 到 JVM 内存中, 生命周期从分钟到月不等, 绝大部分 Block 都会进入 old 区, 只有 Major GC 时才会让它被 JVM 回收它的麻烦主要体现在:
1. HBase Block 的大小不是固定的, 且相对较大, 内存容易碎片化
2. 在 ParNew 算法上, 晋升麻烦麻烦不是体现在拷贝代价上, 而是因为尺寸较大, 寻找合适的空间存放 HBase Block 的代价较高
读缓存优化的思路则是, 向 JVM 申请一块永不归还的内存作为 BlockCache, 我们自己对内存进行固定大小的分段, 当 Block 加载到内存中时, 我们将 Block 拷贝到分好段的区间内, 并标记为已使用当这个 Block 不被需要时, 我们会标记该区间为可用, 可以重新存放新的 Block, 这就是 BucketCache 关于 BucketCache 中的内存空间分配与回收(这一块的设计与研发在多年前已完成), 详细可以参考 : http://zjushch.iteye.com/blog/1751387
42997fe9fa81105c96bfe60f00c29bd7e88c7785
很多基于堆外内存的 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 在任务结束或者代码段结束时, 必须被调用 reset
ShrableHolder 不可直接赋值必须调用 ShrableHolder 提供的方法进行内容的传递
因为 ShrableHolder 不可直接赋值, 需要传递包含生命周期语义的 Block 到函数中时, ShrableHolder 不能作为函数的参数
根据这个范式写出来的代码, 原来的代码逻辑改动很少, 不会引入 if else 虽然看上去仍然有一些复杂度, 所幸的是, 受此影响的区间还是局限于非常局部的下层, 对 HBase 而言还是可以接受的为了保险起见, 避免内存泄漏, 我们在这套框架里加入了探测机制, 探测长时间不活动的引用, 发现之后会强制标记为删除
将 BucketCache 应用之后, 减少了 BlockCache 的晋升开销, 减少了 young GC 时间:
124c501dc766d397bbe5eee44b9036d38dbcd2e0
- e859b25742e535f64d892f75aacd68854dd9948f
- (CCSMap+BucketCache 优化后的效果)
追求极致: AliGC
经过以上两个大的优化之后, 蚂蚁风控生产环境的 young GC 时间已经缩减到 15ms 由于 ParNew+CMS 算法在这个尺度上再做优化已经很困难了, 我们转而投向 AliGC 的怀抱 AliGC 在 G1 算法的基础上做了深度改进, 内存自管理的大堆 HBase 和 AliGC 产生了很好的化学反应
AliGC 是阿里巴巴 JVM 团队基于 G1 算法, 面向大堆 (LargeHeap) 应用场景, 优化的 GC 算法的统称这里主要介绍下多租户 GC
多租户 GC 包含的三层核心逻辑:
1 在 JavaHeap 上, 对象的分配按照租户隔离, 不同的租户使用不同的 Heap 区域;
2 允许 GC 以更小的代价发生在租户粒度, 而不仅仅是应用的全局;
3 允许上层应用根据业务需求对租户灵活映射
AliGC 将内存 Region 划分为了多个租户, 每个租户内独立触发 GC 在个基础上, 我们将内存分为普通租户和中等生命周期租户中等生命周期对象指的是, 既不稍纵即逝, 也不永久存在的对象由于经过以上两个大幅优化, 现在堆中等生命周期对象数量和内存占用已经很少了但是中等生命周期对象在生成时会被 old 区对象引用, 每次 young GC 都需要扫描 RSet, 现在仍然是 young GC 的耗时大头
借助于 AJDK 团队的 ObjectTrace 功能, 我们找出中等生命周期对象中最 "大头" 的部分, 将这些对象在生成时直接分配到中等生命周期租户的 old 区, 避免 RSet 标记而普通租户则以正常的方式进行内存分配
普通租户 GC 频率很高, 但是由于晋升的对象少, 跨代引用少, Young 区的 GC 时间得到了很好的控制在实验室场景仿真环境中, 我们将 young GC 优化到了 5ms
- 124bff446b4f1a76df9ff40cce0d023040d7fbdf
- (AliGC 优化后的效果, 单位问题, 此处为 us)
2f3dbfac848d5ca74c6f8c99c3c4322e05f625dc
fcaa74ac18167a988559fa275478347a46713ae1
云端使用
阿里 HBase 目前已经在阿里云提供商业化服务, 任何有需求的用户都可以在阿里云端使用深入改进的一站式的 HBase 服务云 HBase 版本与自建 HBase 相比在运维可靠性性能稳定性安全成本等方面均有很多的改进, 更多内容欢迎大家关注 https://www.aliyun.com/product/hbase
写在最后 如果你对大数据存储分布式数据库 HBase 等感兴趣, 欢迎加入我们, 一起做最好的大数据在线存储, 联系方式: tianwu.sch@alibaba-inc.com; 也欢迎一起交流问题, 一起学习新技术
转载: https://yq.aliyun.com/articles/277268
资料
HBase:https://pan.baidu.com/s/1jILzgns
知乎 HBase 讨论: https://www.zhihu.com/topic/19600820/hot
hbase-help:http://hbase-help.com/
CSDN HBase 资料库: http://lib.csdn.net/hbase/node/734
这些资料是笔者整理, 以供有大规模结构化需求的用户及 HBase 爱好者学习交流, 以使用 HBase 更好的解决实际的问题
交流
来源: https://www.cnblogs.com/hbase-community/p/8572144.html