本文整理来自英特尔 Java 性能架构师 Eric Kaczmarek 探讨了如何针对 100% YCSB 读取调整 Apache HBase 的 Java 垃圾回收 (GC） 背景：企业Hbase GC时间长，造成Hbase请求超时。
Apache HBase是一个提供 NoSQL 数据存储的 Apache 开源项目。HBase 通常与 HDFS 一起使用，在世界范围内被广泛使用。知名用户包括 Facebook、Twitter、Yahoo 等。从开发人员的角度来看，HBase 是一个“分布式、版本化、非关系型数据库，仿照 Google 的 Bigtable，一个用于结构化数据的分布式存储系统”。HBase 可以通过纵向扩展（即部署在更大的服务器上）或横向扩展（即部署在更多服务器上）轻松处理非常高的吞吐量。 从用户的角度来看，每个查询的延迟非常重要。当我们与用户一起测试、调整和优化 HBase 工作负载时，我们现在遇到了很多真正想要 99% 操作延迟的人。
这意味着从客户端请求到返回客户端的响应的往返行程，全部在 100 毫秒内完成。 有几个因素会导致延迟的变化。最具破坏性和不可预测的延迟入侵者之一是 Java 虚拟机 (JVM) 的“stop the world”垃圾收集（内存清理）暂停。 为了解决这个问题，我们使用 Oracle jdk7u21 和 jdk7u60 G1 (Garbage 1st) 收集器尝试了一些实验。我们使用的服务器系统基于具有超线程（40 个逻辑处理器）的 Intel Xeon Ivy-bridge EP 处理器。它有 256GB DDR3-1600 RAM 和三个 400GB SSD 作为本地存储。这个小型设置包含一个主站和一个从站，配置在一个节点上，负载适当缩放。我们使用 HBase 版本 0.98.1 和本地文件系统来存储 HFile。HBase测试表配置为4亿行，大小为580GB。
我们使用默认的 HBase 堆策略：40% 用于 blockcache，40% 用于 memstore。YCSB 用于驱动 600 个工作线程向 HBase 服务器发送请求 以下图表显示 jdk7u21 使用. 我们指定了要使用的垃圾收集器、堆大小和所需的垃圾收集 (GC)“停止世界”暂停时间。-XX:+UseG1GC -Xms100g -Xmx100g -XX:MaxGCPauseMillis=100
在这种情况下，我们遇到了剧烈波动的 GC 暂停。在初始峰值达到 17.5 秒后，GC 暂停的范围从 7 毫秒到 5 整秒。下图显示了稳态期间的更多详细信息：
图 2 告诉我们 GC 暂停实际上分为三个不同的组：(1) 在 1 到 1.5 秒之间；(1) 在 1 到 1.5 秒之间；(2) 0.007秒至0.5秒之间；(3) 尖峰在 1.5 秒到 5 秒之间。这很奇怪，所以我们测试了最近发布的jdk7u60，看看数据是否有任何不同： 我们使用完全相同的 JVM 参数运行相同的 100% 读取测试：.-XX:+UseG1GC -Xms100g -Xmx100g -XX:MaxGCPauseMillis=100
Jdk7u60 大大提高了 G1 在稳定阶段处理初始尖峰后的暂停时间尖峰的能力。Jdk7u60 在一小时的运行中产生了 1029 次年轻的和混合的 GC。GC 大约每 3.5 秒发生一次。Jdk7u21 进行了 286 次 GC，每次 GC 大约每 12.6 秒发生一次。Jdk7u60 能够将暂停时间控制在 0.302 到 1 秒之间，而没有出现大的峰值。 下面的图 4 让我们更仔细地观察了稳定状态下 150 次 GC 暂停：
在稳定状态下，jdk7u60 能够将平均暂停时间保持在 369 毫秒左右。比jdk7u21好很多，但是还是达不到我们给的100毫秒的要求。–Xx:MaxGCPauseMillis=100 为了确定我们还能做些什么来获得 1 亿秒的暂停时间，我们需要更多地了解 JVM 的内存管理和 G1（垃圾优先）垃圾收集器的行为。下图显示了 G1 如何进行 Young Gen 收集。
当 JVM 启动时，根据 JVM 启动参数，它要求操作系统分配一个大的连续内存块来托管 JVM 的堆。该内存块由 JVM 划分为多个区域。
如图 6 所示，Java 程序使用 Java API 分配的每个对象首先进入左侧年轻代的 Eden 空间。一段时间后，Eden 变满，触发了 Young generation GC。仍然被引用（即“活着”）的对象被复制到 Survivor 空间。当对象在年轻代中存活了几次 GC 后，它们就会被提升到老年代空间。当 Young GC 发生时，Java 应用程序的线程会停止，以便安全地标记和复制活动对象。这些停止是臭名昭著的“停止世界”GC 暂停，这使得应用程序在暂停结束之前没有响应。
老一代也会变得拥挤。在某个级别（由默认为总堆的 45% 控制）会触发混合 GC。它收集年轻一代和老一代。混合 GC 暂停由年轻代在混合 GC 发生时清理所需的时间控制。-XX:InitiatingHeapOccupancyPercent=? 所以我们可以在 G1 中看到，“停止世界”GC 暂停主要取决于 G1 标记和复制活动对象到 Eden 空间之外的速度。考虑到这一点，我们将分析 HBase 内存分配模式将如何帮助我们调整 G1 GC 以获得我们期望的 100 毫秒暂停。 在 HBase 中，有两个内存结构消耗了它的大部分堆：用于BlockCache读取操作的缓存 HBase 文件块，以及缓存最新更新的 Memstore。
新对象形成LruBlockCache，Memstore首先进入Young generation的Eden空间。如果它们存活的时间足够长（即，如果它们没有被逐出LruBlockCache或从 Memstore 中清除），那么在几次 GC 之后，它们就会进入 Java 堆的老年代。当 Old generation 的可用空间小于给定threshOld（InitiatingHeapOccupancyPercent开始）时，混合 GC 开始并清除 Old generation 中的一些死对象，从 Young gen 复制活动对象，并重新计算 Young gen 的 Eden 和 Old gen 的HeapOccupancyPercent. 最终，当HeapOccupancyPercent达到一定水平时，FULL GC会发生一个巨大的“停止世界” GC 暂停以清理 Old gen 中的所有死亡对象。 在研究了“”生成的 GC 日志之后，我们注意到在 HBase 100% 读取期间，它从未增长到足以引发完整 GC 的程度。我们看到的 GC 暂停主要由年轻一代“停止世界”暂停和随时间增加的引用处理所主导。
-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicyHeapOccupancyPercent
完成该分析后，我们对默认的 G1 GC 设置进行了三组更改：
- Use开启该标志时，GC在Young和mixed GC时使用多线程处理不断增加的引用。使用 HBase 的这个标志，GC 重新标记时间减少了 75%，整体 GC 暂停时间减少了 30%。-XX:+ParallelRefProcEnabled
- Set -XX:-ResizePLAB and -XX:ParallelGCThreads=8+(logical processors-8)(5/8)Promotion Local Allocation Buffers (PLAB) 在 Young 收集期间使用。使用了多个线程。每个线程可能需要在 Survivor 或 Old 空间中为正在复制的对象分配空间。PLAB 需要避免线程竞争管理空闲内存的共享数据结构。每个 GC 线程都有一个 PLAB 用于 Survival 空间，一个用于 Old 空间。我们希望停止调整 PLAB 的大小，以避免 GC 线程之间的大量通信成本，以及每次 GC 期间的变化。我们希望将 GC 线程的数量固定为 8+(logical processors-8)( 5/8). 这个公式是 Oracle 最近推荐的。通过这两个设置，我们能够在运行期间看到更平滑的 GC 暂停。
- 将 100GB 堆的默认值从 5更改为 1 根据 的输出，我们注意到 G1 未能满足我们期望的 100GC 暂停时间的原因是处理 Eden 所花费的时间。换句话说，在我们的测试中，G1 平均需要 369 毫秒来清空 5GB 的 Eden。然后，我们使用标志将 Eden 大小从 5 降低到 1。通过此更改，我们看到 GC 暂停时间减少到 100 毫秒。-XX:G1NewSizePercent-XX:+PrintGCDetails and -XX:+PrintAdaptiveSizePolicy-XX:G1NewSizePercent=
从这个实验中，我们发现G1清理Eden的速度约为每100毫秒1GB，或者对于我们使用的HBase设置，每秒10GB。
基于该速度，我们可以设置Eden 大小可以保持在 1GB 左右。例如：-XX:G1NewSizePercent=
- 32GB 堆，-XX:G1NewSizePercent=3
- 64GB 堆，-XX:G1NewSizePercent=2
- 100GB及以上堆，-XX:G1NewSizePercent=1
- 所以我们最终的 HRegionserver 命令行选项是：
- -XX:+UseG1GC
- -Xms100g -Xmx100g（我们测试中使用的堆大小）
- -XX:MaxGCPauseMillis=100（测试中所需的 GC 暂停时间）
- –XX:+ParallelRefProcEnabled
- -XX:-ResizePLAB
- -XX:ParallelGCThreads= 8+(40-8)(5/8)=28
- -XX:G1NewSizePercent=1
这是运行 100% 读取操作 1 小时的 GC 暂停时间图表：
在此图表中，即使是最高的初始稳定峰值也从 3.792 秒减少到 1.684 秒。最开始的峰值不到 1 秒。结算后，GC 能够将暂停时间保持在 100 毫秒左右。下图比较了 jdk7u60 在稳定状态下使用和不使用调优的运行情况：
我们上面描述的简单 GC 调整给出了理想的 GC 暂停时间，大约 100 毫秒，平均 106 毫秒和 7 毫秒标准偏差。
经验总结：
HBase 是一个响应时间关键的应用程序，它要求 GC 暂停时间是可预测和可管理的。使用 Oracle jdk7u60，根据报告的 GC 信息，我们能够将 GC 暂停时间调低到我们想要的 100 毫秒。-XX:+PrintGCDetails -XX:+PrintGCTimeStamps -XX:+PrintAdaptiveSizePolicy
