做HBase运维的人迟早都会面对一个问题机器配置一样角色不同到底该怎么给Master和RegionServer分配JVM内存我见过不止一个团队把Master和RegionServer的JVM参数配成完全一样32GB堆一把梭结果集群状态看着正常Master却隔三差五和ZooKeeper会话超时RegionServer又因为堆内对象碎片频繁触发Full GC。其实HBase的master和regionserver的jvm调优核心不是把参数两边抄一遍而是先理解两个角色的内存模型差异再根据实际读写压力去配堆大小、GC策略和缓存比例。这篇内容我把这段时间的实战经验完整梳理出来适合正准备给HBase集群做第二轮JVM调优的人参考。1. Master和RegionServer的内存模型差异为什么不能一套参数打天下1.1 Master到底在堆里放了什么很多新手容易有一个误解HBase的Master进程是不是管着所有数据其实不是。HBase的Master不参与用户数据的读写它主要管理元数据、Region分配、表结构、负载均衡和故障转移这类集群级操作。用户数据被分成一个个Region分散在RegionServer上真正的内存消耗大头在RegionServer侧。Master进程的堆里装着的东西大概有这几类每个namespace、表的TableDescriptor和权限信息每个Region的RegionStateNode也就是Region的分配状态、在线离线转换进度后台任务的状态比如balancer、移动Region、split任务的队列信息各RegionServer上报的负载、磁盘、请求统计等。所以Master堆大小跟集群规模有关系跟数据总量没有直接关系。数据量再大只要Region数量不多Master堆压力也不会大。但反过来如果集群有十几万个Region即使数据量只有几百GBMaster堆也会因为Region状态对象太多而不够用。我给一个模拟项目X的集群调优时最初照搬了32GB堆给Master结果Region数量到8万以后Master经常出现几秒钟的STW暂停导致和ZooKeeper的会话超时RegionServer上报的heartbeat也经常延迟。后来把Master堆降到12GBGC暂停反而短了很多。原因不复杂。堆越大G1的并发标记周期要扫描的对象越多remark和cleanup阶段耗时越长。Master本身不承载用户请求堆内对象绝大多数是长期存活的状态对象它们很容易晋升到Old区每次Full GC都会拖累Master的响应能力。所以Master堆不是越大越好它需要的是“够用且不过量”。1.2 RegionServer的内存大头在哪RegionServer的内存模型要复杂得多。堆内主要被三块内容占据MemStore、BlockCache以及各种Java对象和RPC处理缓冲。MemStore是写入路径的缓存数据先写WAL再写到MemStore等到MemStore达到阈值后刷成HFileBlockCache是读取路径的缓存HFile中的数据块、索引块和布隆过滤器会被缓存到堆内剩下的堆内存用于Region对象的元数据、HFile引用、Scanner状态、RPC请求和响应对象等。RegionServer的堆大小直接影响能同时服务的Region数量、写入吞吐和读缓存命中率。它才是HBase调优的真正主战场。一个很重要的点是RegionServer堆里的MemStore和BlockCache都不是固定大小的它们由各自的比例参数控制。默认配置下MemStore最多可以占到堆的40%BlockCache最多也是40%。也就是说有80%的堆可以被这两块“吃掉”剩下的20%才留给Region对象、RPC和内部异步任务。一旦业务读写压力上来这20%的余量经常是RPC延迟飙升的罪魁祸首因为MemStore和BlockCache会自动扩张把其他对象的生存空间挤掉。1.3 不同步调整会出现的典型问题如果Master和RegionServer用同一套参数通常会出现三种问题第一种Master堆给得太大。Region数量不高时Master堆大部分处于空闲状态但因为GC要管理的堆范围很大minor GC和并发标记的耗时都会变长最终表现为Master“看起来没事但什么操作都慢半拍”。第二种RegionServer堆给得不够。写入量大的集群MemStore很容易触顶然后RegionServer会强制阻塞写入并触发flush线上现象就是大量RegionTooBusy异常。读取量大的集群BlockCache不够会导致HFile块反复从磁盘加载读延迟飙升。第三种两者之间的JVM参数互相干扰。最常见的是在一个物理机上同时部署Master和RegionServer然后GC参数里用了过多的GC线程配置导致两台Java进程竞争CPU。这个问题在混合部署环境里特别明显。后面我会专门讲怎么区分配置和部署策略。2. 堆大小规划从物理机配置到Master和RegionServer的Xmx取舍2.1 32GB这个坎是怎么来的很多HBase生产配置里RegionServer的堆大小都是32GB这不是随便拍出来的。JVM在32GB堆以下会默认开启普通对象指针压缩也就是通常说的压缩指针。压缩指针能大幅减少堆内对象引用占用的空间同样一批对象在32GB堆内的实际占用可能比在40GB堆还少。如果在64GB物理机上给RegionServer分配40GB甚至更大的堆为了维持压缩指针还额外开启了-XX:UseCompressedOops和-XX:ObjectAlignmentInBytes调起来非常麻烦还容易产生更多GC碎片。所以多数团队的做法是一台物理机上放多台RegionServer每台堆不超过32GB用多个进程去吃掉大内存机器。我见过一个在生产环境里运行的方案是某公司一台256GB内存的机器部署了7个RegionServer其中6个RegionServer堆各32GB另一个堆16GB跑Master和其他辅助服务。物理内存虽然看上去差不多占满了但系统层还留了几十GB给Page Cache。这套方案的GC表现反而比单RegionServer分配256GB堆好得多。大堆的另一个问题是GC暂停时间不可控。G1的并发周期在老年代占用达到阈值后启动如果堆内全是存活对象并发回收基本帮不上忙最终还是会走向Full GC。而一个80GB堆的Full GC暂停时间经常以秒为单位。对RegionServer来说几百毫秒的STW都会直接影响写入和延迟。2.2 Master堆给多少合适我给Master堆的通用建议是4GB到16GB之间具体看Region数量。一个几千Region的小集群4GB完全够十万Region的大集群给到16GB也够了。再往上加意义不大反而因为GC周期变长拖垮Master。判断Master堆是否够用最简单的指标是看Region数量。HBase的Master在分配和移动Region时会为每个Region维护状态节点一个Region状态节点以及它关联的对象在Master堆里大概占几百字节到几KB。10万个Region也就是几百MB到1GB左右的占用。再加上表描述、namespace、权限和任务队列也就2GB到4GB。如果Master堆一直被推到80%以上第一反应不应该是加内存而是查是不是内存泄漏或者Region数量是不是已经膨胀到了不该有的水平。我在某个集群里就见过Master堆持续上涨最后发现是因为一个版本的后台任务管理器在大量Region移动时没有及时释放状态对象。那是版本问题不是堆不够。Master的GC参数也值得单独调。它和RegionServer不一样不需要追求吞吐率而是要尽量降低单次GC的最大暂停时间因为Master和ZooKeeper之间的会话超时非常敏感。ZooKeeper的会话超时通常是几十秒如果一次Full GC把Master停了5秒以上线上虽然不会立刻触发主备切换但会积累很多未确认的操作请求Master恢复后要花很长时间去重放任务给人的体感就是“集群又抖了一下”。2.3 RegionServer堆与JVM HousekeepingRegionServer的堆大小通常由业务模型决定但有几个硬约束必须遵守。第一要给系统Page Cache留空间。RegionServer在读取HFile时操作系统会用Page Cache缓存最近读过的文件块。即使BlockCache已经缓存了一部分Page Cache仍然能显著降低小文件随机读的延迟。如果把物理机内存全部塞给JVM进程Page Cache几乎没有HBase的读性能会直接打折。一般建议至少留出16GB到32GB给操作系统再留几个GB给堆外网络缓冲。第二RegionServer堆至少要能装下所有Region的MemStore基线占用。这里的MemStore基线不是指全量写入而是每个Region至少有一个MemStore在运行即使没有写入它也会占用一部分内存。Region数量越多这个过程对象开销越大。所以Region数量和堆大小之间要有一个平衡别让堆内一半空间都变成Region元数据。第三RPC层的缓冲经常被忽略。RegionServer的堆内有一部分内存用于处理Netty和RPC请求对象吞吐量大的集群这部分占用可能占到堆的5%到10%。如果把MemStore和BlockCache的百分比加得太高RPC内存不足时会先表现出GC频繁然后是请求超时。后面第3章我会专门讲百分比怎么分配。3. 缓存与写入内存的分配比例MemStore和BlockCache的跷跷板3.1 默认值的适用场景与误区HBase默认配置里hfile.block.cache.size是0.4hbase.regionserver.global.memstore.size也是0.4。这组默认值在HBase开源社区的老版本中比较合理因为当年的集群普遍读多写少而且硬件不强需要把BlockCache给足。但现在很多业务其实不符合这个默认场景。写入量大的时序数据、日志流数据MemStore的需求远大于BlockCache。如果你把默认值直接搬到写多读少的集群BlockCache命中率可能只有10%到20%大量的堆内存被浪费MemStore却常常因为空间不足触发强制flush。误区最大的一点是以为这两个值加到越大越好。实际上它们加起来不能超过0.8因为堆里必须给Region对象、HFile的索引对象、RPC缓冲等留出至少20%的余量。如果你把MemStore和BlockCache加起来设成0.9平时似乎没问题一旦写入压力上来其他的内存立刻不够用表现为GC飙高、请求超时甚至OOM。3.2 读密集和写密集集群的比例调整我的调整思路是这样的先判断业务是读密集还是写密集把两类配置分开。读密集的集群典型特征是BlockCache命中率很高、RegionServer的Scanner请求多、HFile的随机读比例大。这种场景可以把BlockCache给到0.45到0.5MemStore控制在0.25到0.3。需要注意的是如果BlockCache超过0.5其他堆内对象的压力会很大即使命中率高也会因为GC恶化影响整体延迟。写密集的集群典型特征是写入吞吐高、Flush频繁、MemStore压力大。这种场景可以把MemStore给到0.4到0.45BlockCache降到0.2到0.25。很多大数据写入任务的block cache命中率本来就不高留太多缓存没什么收益。还有一个最容易被忽略的点MemStore在达到上限之前会有一个global memstore lower limit。HBase默认在MemStore总占用达到上限的95%时就开始对所有Region做强制flush防止写入完全阻塞。在写密集场景下如果MemStore经常触顶可以适当调整这个lower limit的比例比如改成0.9让它提前一点flush避免一次性积压太多。下面是我常用的两种调整组合可以直接作为起点参考场景hfile.block.cache.sizehbase.regionserver.global.memstore.sizelower limit读多写少0.450.30.9写多读少0.250.40.9混合均衡0.350.350.95注意这几个比例是在32GB堆基础上估算的。如果你的RegionServer只给了16GB同样的比例下实际内存余量会更紧张建议把MemStore和BlockCache的总占比往0.7以下压。3.3 HBase 2.x的堆外缓存选项HBase 2.x开始引入了堆外BlockCache和堆外MemStore的选项这让很多人以为可以摆脱JVM堆的限制。我的实际体验是堆外缓存确实能降低GC压力但代价是复杂度上了一个台阶不是所有人第一次就能玩明白。堆外BlockCache最常见的实现是BucketCache它可以配合堆内LruBlockCache使用把部分缓存放到DirectMemory区域。开启后堆内BlockCache的大小可以降下来GC压力会小很多。但BucketCache有它自己的问题命中率不如堆内缓存高而且需要额外划分DirectMemory如果分配太多系统内存不够反而会挂进程。堆外MemStore则要求整个HBase集群的版本、RF、WAL实现都匹配如果配置不完整数据一致性会出问题。我对大多数团队的推荐是如果JVM堆还在32GB这个安全线以内先用好堆内配置不要急着上堆外方案。等你的RegionServer堆超过64GB、GC问题实在压不住再考虑堆外BlockCache。4. GC策略与参数落地G1在HBase里的实操参数4.1 选CMS还是G1HBase社区对GC策略的态度有一个明显的历史变化。早期HBase版本推荐CMS因为CMS对老年代的并发回收能有效减少Full GC在Java 8和HBase 1.x时代是主流选择。HBase 2.x之后官方和社区都更推荐G1。原因在于G1可以把堆划分为多个Region以增量方式回收理论上能设定一个最大暂停时间目标。Java 8环境下用CMS不是不能用但Java 9之后CMS就被标记为废弃Java 14直接把CMS移除了。如果你的集群还跑在Java 8上并且用的是老版本HBaseCMS可以继续用着。只要是真·Java 8 HBase 2.x我建议直接上G1。G1对HBase比较友好的一点是它能更好地控制停顿时间。RegionServer上的请求都是毫秒级的一次200毫秒的Minor GC可以接受一次2秒的Full GC就不可接受。G1可以把停顿时间控制在目标值附近至少比堆大后CMS的并发模式失败要温和。不要追求暂停时间越短越好。-XX:MaxGCPauseMillis设置得太低比如50ms会让G1频繁调整年轻代大小导致GC次数反而变多吞吐率下降。HBase里我通常把RegionServer的MaxGCPauseMillis设在100到200ms之间Master则设在50到100ms之间。4.2 一套可以起步的G1参数下面这套参数是我在模拟项目X的RegionServer上起步用的总体表现稳定可以作为参考-Xms32g -Xmx32g -XX:UseG1GC -XX:MaxGCPauseMillis150 -XX:G1HeapRegionSize16m -XX:InitiatingHeapOccupancyPercent60 -XX:G1ReservePercent10 -XX:MaxTenuringThreshold15 -XX:ParallelRefProcEnabled逐个说下关键点。-Xms和-Xmx一样这是必选项。HBase进程启动后如果能避免动态调整堆大小可以少做很多无谓的堆扩容操作。我们线上全部配置为固定堆。G1HeapRegionSize16m在32GB堆下比较合适。G1的Region数量控制在2048左右太低会导致分区粒度过粗太高又会让Humongous对象分配变得频繁。如果你的RegionServer堆只有8GB或16GB可以考虑8m的Region大小。这个参数不是必须手动设置的但显式写出来可以方便后面排查Humongous分配问题。InitiatingHeapOccupancyPercent60表示老年代使用率到60%时开始并发标记。如果设得太低G1会频繁做并发周期浪费CPU太高则不健康。在32GB堆和写密集场景下60比较稳妥。如果是读密集场景老年代增长本来就慢可以设到70。MaxTenuringThreshold15是让年轻代对象最多熬过15次MinorGC才进入老年代配合SurvivorRatio可以减小对象过早晋升到老年代的概率。HBase的MemStore里大量对象生命周期很短能留在年轻代就尽量留在年轻代。Master进程可以用类似参数但堆和暂停目标调低-Xms12g -Xmx12g -XX:UseG1GC -XX:MaxGCPauseMillis80 -XX:G1HeapRegionSize8m -XX:InitiatingHeapOccupancyPercent60 -XX:ParallelRefProcEnabled4.3 从GC日志反推参数问题参数设置完之后最怕的就是拍脑袋调完不看日志。GC日志才是调优的最终裁判。Java 8下我习惯在hbase-env.sh里给RegionServer加上这样的GC日志参数-Xloggc:/data/logs/hbase-rs-gc.log -XX:PrintGCDetails -XX:PrintGCDateStamps -XX:UseGCLogFileRotation -XX:NumberOfGCLogFiles10 -XX:GCLogFileSize128mJava 11及以上版本用统一日志参数-Xlog:gc*:file/data/logs/hbase-rs-gc.log:time,uptime,level,tags:filecount10,filesize128m拿到日志后我重点关注几个指标GC Pause的平均值和中位数如果中位数在100ms以下说明年轻代回收正常Concurrent Cycle是否频繁启动如果几分钟一次多半是InitiatingHeapOccupancyPercent设太低有没有Humongous Allocation记录如果频繁出现说明堆里经常分配大对象可能是BlockCache里的某个缓存块或者BloomFilter申请了过大内存Full GC次数。G1下Full GC一旦出现基本是并发标记来不及回收或者晋升失败优先查堆内是否有内存泄漏。我见过一个集群RegionServer堆32GBBlockCache给了0.45MemStore给了0.3看起来比例合理但GC日志里每半小时一次Full GC。后来发现是某个表的HFile块大小设置得特别大导致一个BlockCache块接近2MB在高并发读取时触发G1 Humongous分配将整块内存的连续空间切碎。把表的BLOCKSIZE缩到64KB之后Full GC立刻消失了。5. 除了JVM本身Region数、布隆过滤器和操作系统页缓存5.1 Region数量如何影响JVMJVM调优不能只看Java进程内部堆外的对象结构同样影响GC。Region数量是一个被很多人忽视的变量。一个Region在RegionServer上至少会占用一块MemStore空间、一个HFile引用列表、一组BloomFilter元数据以及一堆内部状态对象。大量Region会让堆内的“常驻对象”越来越多这些对象不会轻易回收导致老年代持续增长。我见过一个集群Region数量有6000多个每台RegionServer上接近1500个Region。虽然单个Region的数据量不大但RegionServer的JVM堆里有大量Region级对象GC扫描的时间明显变长。后来把这个表的分区策略改成了预分区减少Region数量同时把Region大小调整到10GB以上GC表现立刻好转。Region数量和RegionServer堆大小的关系我自己的经验数据是100GB以内的数据量Region大小在5GB到20GB之间比较健康一台RegionServer上的Region数量控制在200到1000之间。如果Region数超过2000优先做major compaction或调整split策略而不是加JVM内存。5.2 BlockCache与HFile的相互作用BlockCache不是越大越好这点要特别注意。HFile的每个数据块被读入BlockCache后在Java堆里会以缓存条目存在。如果缓存了大量数据块堆内碎片和GC压力都会上升。读多写少的场景里BlockCache给到0.5可能命中率很好但一旦HFile数量过多缓存里的每个文件块索引对象也会占用额外内存。BloomFilter是另一个堆内存消耗大户。每个HFile可以配置BloomFilter启用后会在读路径上减少不必要的磁盘访问但它本身会驻留在内存中。一个表如果每个RegionServer有几百个HFile每个HFile都带BloomFilter累计的内存占用非常可观。遇到BlockCache命中正常但堆内存持续偏高的情况可以检查一下hfile.bloom.filter.enabled相关的表配置必要时改成ROW级别的BloomFilter而不是ROWCOL级别。GC调优到后期往往就是这些“堆外但接近堆”的因素在起作用。我已经不止一次在群里看到有人问“为什么BlockCache命中率90%G1还频繁GC”最后都是被HFile数量和BloomFilter的内存占用坑了。5.3 给OS留内存把物理机内存全部分给JVM进程是一个极其常见的错误。RegionServer读HFile时底层的读操作首先会经过操作系统Page Cache。Page Cache命中率高时即使BlockCache没有命中也只需要在内核态读一次内存就能返回。我在一台128GB内存的机器上做过对比实验RegionServer堆给96GB时操作系统只剩不到8GB热点数据读P99超过80ms降到64GB堆后系统内存剩下约24GB同样的读请求P99降到30ms以内。所以调JVM堆时一定要看整台物理机的内存分配结构不要只盯着RegionServer的Xmx。我的建议是每台物理机至少给操作系统留下25%左右的内存最少不低于16GB。如果机器上还跑着监控Agent、采集Agent也要提前扣掉。6. 一次线上Master频繁失联的排查过程复盘6.1 现象与初步判断去年我接手一个集群优化时线上最明显的现象是Master进程每隔两三天就会出现一次主备切换。从监控看Master在切换前有明显的GC停顿然后与ZooKeeper的会话超时另一个Master接管。第一反应是Master堆不够直接查了Master堆占用发现Old区只有60%左右并没有到瓶颈。然后查了GC日志发现Master步给32GB堆时每次minor GC平均80ms但每隔几个小时会出现一次300ms到500ms的G1 remark暂停。这个暂停长度对普通业务无所谓但对Master和ZooKeeper之间的心跳是个隐患。我一开始没动配置先判断是Region数量太多还是GC参数不合适。当时Region总数量大概9万对12GB堆来说空间充足但对32GB堆G1每次并发标记要扫描的对象数量被放大了很多。问题根源确实是Master堆给得过大。6.2 用jstat和GC日志定位根因排查工具我用的是jstat没用昂贵的人工线程dump。先看整个进程的内存变化jstat -gcutil master-pid 5000输出里可以看到Eden、Survivor、Old区的百分比以及FGCTFull GC累计时间和GCT总GC时间。Master进程的FGCT持续增长但Old区比例一直没到100%说明不是内存泄漏而是每次Full GC成本太高。又抓了一段GC日志做时间分布分析看到remark阶段的暂停时间占到了整个G1并发周期的四分之一。G1在扫描根对象时Master堆里的Region状态对象数量多且分散导致根扫描阶段耗时更长。结合Heap占用只有50%左右判断不需要32GB堆于是把Master的Xmx从32GB降到了12GB同时把MaxGCPauseMillis设成80ms。改完后Master的GC暂停时间从之前的平均300ms降到100ms以内主备切换再也没有因为GC触发。这里有个经验Master堆不是越大越安全对于长期存活对象占比非常高的进程堆越大反而让GC扫描范围变大停顿时间变长。6.3 修改后的配置与效果最后调整完的Master配置是这个样子HBASE_MASTER_OPTS$HBASE_MASTER_OPTS -Xms12g -Xmx12g -XX:UseG1GC -XX:MaxGCPauseMillis80 -XX:G1HeapRegionSize8m -XX:InitiatingHeapOccupancyPercent60 -XX:ParallelRefProcEnabledRegionServer那边没有动堆大小只是把BlockCache比例从默认的0.4降到了0.35MemStore保持在0.4。因为这套集群是写稍多于读BlockCache留少一点把堆内空间更多让给MemStore和RPC缓冲。调整后观察了两周Master的GC日志里基本找不到超过200ms的暂停。RegionServer的读延迟没有明显恶化写阻塞次数下降了30%左右因为MemStore有更充足的空间flush触发更均匀。7. 按这个顺序做一遍基本不会跑偏如果你准备给现有集群做Master和RegionServer的JVM调优我的建议是按照下面这个顺序来不要一上来就改GC参数。先确认两个角色各自的需求。Master堆按Region数量估12GB到16GB基本够RegionServer堆按物理机内存、业务读写比例、Region数量综合估单进程尽量别超过32GB。再调内存比例。先判断读写偏向把BlockCache和MemStore调到合理的组合留出20%到30%给其他堆内对象。这一步不做后面GC参数改得再细都会因为堆内空间失衡而失败。然后配GC策略。主流直接上G1先用一套标准参数跑起来再通过GC日志调整InitiatingHeapOccupancyPercent和MaxGCPauseMillis。切忌只调比例不调GC或者只调GC不改比例。最后监控验证。关注四类指标Master的会话超时次数、RegionServer的GC暂停P99、BlockCache命中率、写阻塞次数。任何一个指标恶化都要回到底层配置重新思考而不是简单加大堆。这套流程我在多个集群上重复过虽然没有哪个参数组合是万能的但只要按“角色差异→内存比例→GC参数→监控验证”这个链路走大概率能在一个版本迭代内把HBase的稳定性明显拉起来。