企业官网建设流程全解析

1. 项目概述：这不是调参手册，而是一份HBase生产环境“止血包”

你点开这个标题，大概率不是想学HBase怎么安装、怎么建表——这些内容网上一搜一大把，但真正卡住你的，是查个简单Scan要8秒、RegionServer隔三差五OOM、写入吞吐卡在5000 QPS上不去、或者凌晨三点收到告警说某个Region正在分裂失败……这些不是理论问题，是服务器在你耳边喘粗气。我带过的三个大数据平台项目里，有两次核心瓶颈都出在HBase层，一次是某电商订单轨迹系统，一次是某IoT设备时序数据平台，它们的共性不是配置没调好，而是对HBase底层机制的理解和优化动作完全脱节。所谓“HBase优化”，从来不是堆参数、改配置、重启服务这么简单；它是一套围绕数据模型设计→写入路径控制→读取路径压缩→资源调度协同→故障自愈能力五个环节的闭环工程。本篇不讲“hbase.regionserver.handler.count设成多少合适”这种碎片答案，而是还原一个真实场景：当你接手一个已上线半年、日增2TB数据、查询延迟持续攀升的HBase集群时，从诊断到落地的完整推演链。所有代码、配置、命令、监控指标全部来自某金融风控平台的真实压测与线上调优记录，已脱敏处理，可直接复用。适合两类人：一是刚从Hadoop生态入门、正被HBase各种“慢”折磨的工程师；二是已有一定经验、但总在“改了参数没效果”和“不知道该看哪个指标”之间反复横跳的运维/开发同学。

2. HBase优化的本质：一场围绕LSM-Tree与分布式协调的精密手术

2.1 为什么“调参”常常失效？先拆穿三个认知陷阱

很多同学一上来就翻《HBase权威指南》抄参数，结果发现：

• 把hfile.block.cache.size从0.4调到0.6，缓存命中率没升反降；
• 把hbase.hstore.compactionThreshold从3改成10，Compaction风暴更猛烈了；
• 甚至把hbase.regionserver.global.memstore.size从0.4调低到0.3，写入反而开始大量Reject。

这不是参数错了，是你没看清HBase的“身体结构”。它的核心不是单机数据库，而是一个以LSM-Tree为存储引擎、以ZooKeeper为协调中枢、以Region为调度单元、以WAL+MemStore+HFile为三级数据流的分布式状态机。优化动作必须匹配其内在节奏，否则就是给高速运转的涡轮发动机乱拧螺丝。下面这三张图，是我画给团队新人最常复用的“决策地图”，它不教你参数值，而是告诉你什么时候该动哪根神经：

提示：所有优化动作，必须回答三个问题：① 这个动作影响的是写路径还是读路径？② 它改变的是单Region行为，还是全局集群行为？③ 它是否引入新的资源竞争（如CPU、网络、磁盘IO）？

2.1.1 写入路径的“三道闸门”：WAL → MemStore → HFile

写入不是“一条直线”，而是三段式流水线：

1. WAL（Write-Ahead Log）：数据首先进WAL落盘（确保崩溃可恢复），再进内存；
2. MemStore：内存中的有序写缓冲区，按RowKey排序，达到阈值触发Flush；
3. HFile：Flush后生成的SSTable文件，最终通过Compaction合并小文件。

关键矛盾在于：WAL保障可靠性，MemStore保障写入吞吐，HFile保障读取效率——三者天然存在资源争夺。比如，WAL写太慢（磁盘IO瓶颈），MemStore就卡住不刷；MemStore刷太勤（阈值设太低），HFile小文件爆炸；HFile Compaction太猛（并发太高），又会抢光磁盘IO，反过来拖慢WAL写入。这就是为什么单纯调大hbase.hregion.memstore.flush.size（默认128MB）可能适得其反——如果底层磁盘IOPS只有3000，一次Flush写128MB要400ms，那10个Region同时Flush，整个RegionServer就卡死了。

2.1.2 读取路径的“四层缓存”：BlockCache → BloomFilter → BlockIndex → DataBlock

读取也不是“查一次磁盘”，而是四级漏斗：

• BloomFilter：快速判断某RowKey“肯定不存在”，避免无效磁盘寻址（内存开销极小，收益极大）；
• BlockIndex：定位DataBlock在HFile中的物理偏移（类似书的目录）；
• BlockCache：缓存热点DataBlock（默认LRU，但实际应配BucketCache分层）；
• DataBlock：真正的数据块，每次读取至少加载一个Block（默认64KB）。

这里最大的误区是：“加大BlockCache就等于提升读性能”。错。BlockCache只缓存DataBlock，而BloomFilter和BlockIndex才是决定“一次Get是否需要读磁盘”的关键。某次我们把BlockCache从4G加到8G，QPS没变，但GC时间翻倍——因为JVM堆变大，CMS GC停顿从50ms涨到300ms。后来我们关掉BlockCache，只启用BloomFilter（ROWCOL模式），配合预分区，随机Get延迟反而从120ms降到35ms。原因？90%的请求被BloomFilter当场拦截，根本没走到BlockCache这一步。

2.1.3 分布式协调的“心跳陷阱”：ZK Session Timeout与Region迁移成本

HBase依赖ZooKeeper做元数据管理与故障转移，但ZK不是万能胶。一个典型问题是：RegionServer挂了，ZK检测到并通知Master，Master再分配Region，整个过程耗时往往超过30秒。而在这30秒内，所有发往该Region的请求都会超时重试，造成客户端雪崩。很多人第一反应是“调小zookeeper.session.timeout”，比如从40秒改成10秒。这是危险操作——ZK Session Timeout不是“故障检测时间”，而是“客户端与ZK连接的最大空闲时间”。设太小会导致网络抖动时频繁断连重连，引发更多Region重新分配。真实解法是：用hbase.master.maximum.regionserver.retries控制重试次数 +hbase.master.regionserver.recovery.timeout控制单次恢复超时 +hbase.regionserver.restart.on.zk.expire关闭自动重启，把故障转移从“被动等待”变成“主动熔断+人工介入”。

2.2 优化决策树：从现象反推根因的5步法

面对一个“慢”的HBase集群，我从不打开hbase-site.xml，而是按以下顺序排查，每步都有明确指标和验证手段：

这个表格不是教科书，而是我贴在工位旁的“故障速查贴”。每次接到告警，我就按顺序打钩，90%的问题能在前三步定位。比如，上周某实时风控表突然Get延迟飙升，第一步Client端测试正常，第二步发现RegionServer CPU 95%但IO Wait仅5%，第三步查到某个Region QPS达32000，远超其他Region（平均800），立刻确认是RowKey设计缺陷——用设备ID做前缀，导致同一厂商设备集中在一个Region。解决方案不是调参数，而是立刻执行Split + 重新设计RowKey为hash(device_id) + device_id + timestamp，两小时后延迟回归正常。

3. 实操核心：从诊断到落地的7个不可跳过的硬核步骤

3.1 步骤一：建立基线——用真实流量跑出“健康快照”

优化不是空中楼阁，必须基于当前集群的真实负载画像。我拒绝任何“凭经验调参”，坚持用三组基线数据说话：

1. 空载基线：集群无业务流量时，各RegionServer的MemStore size、BlockCache used、WAL edit count等基础指标；
2. 轻载基线：模拟50%日常流量（用PerformanceEvaluation工具），记录avg get latency、95th percentile scan time、compaction queue length；
3. 重载基线：模拟120%峰值流量，重点观察RegionServer process heap usage、GC time per minute、HDFS write bandwidth。

注意：所有基线必须在同一时间段（避开HDFS Balancer、NameNode Checkpoint等后台任务）采集，且至少持续30分钟。我习惯用hbase org.apache.hadoop.hbase.PerformanceEvaluation配合自定义脚本，每5秒抓一次Metrics，存入InfluxDB，用Grafana画趋势图。没有可视化基线，一切优化都是蒙眼走路。

实操代码：一键采集重载基线（含注释）

#!/bin/bash # 文件名：hbase_baseline.sh # 功能：在指定表上施加120%峰值QPS压力，持续30分钟，采集关键指标 TABLE_NAME="risk_event_log" PEAK_QPS=8000 # 基于历史监控确认的峰值QPS DURATION=1800 # 30分钟，单位秒 CONCURRENCY=200 # 并发线程数，根据QPS和平均延迟计算：8000 / (100ms/1000) ≈ 800，但需留余量，设200足够 # 1. 清理旧数据，确保测试纯净 echo "Cleaning old test data..." hbase shell <<EOF disable '$TABLE_NAME' drop '$TABLE_NAME' create '$TABLE_NAME', {NAME => 'cf', TTL => 604800} enable '$TABLE_NAME' EOF # 2. 启动压力测试（Get随机RowKey） echo "Starting GET pressure test at $(date)..." nohup hbase org.apache.hadoop.hbase.PerformanceEvaluation \ --rows=1000000 \ --table=$TABLE_NAME \ --presplit=20 \ --compress=SNAPPY \ --valueSize=1024 \ --batchSize=100 \ --clients=$CONCURRENCY \ --write=false \ --read=true \ --randomRead=true \ --multiGet=10 \ > /tmp/hbase_get_baseline.log 2>&1 & # 3. 同时启动指标采集（每10秒抓一次） echo "Starting metrics collection..." METRICS_FILE="/tmp/hbase_metrics_$(date +%s).csv" echo "timestamp,regionserver,memstore_size_mb,blockcache_hit_ratio,wal_sync_time_ms,compaction_queue" > $METRICS_FILE while [ $(($(date +%s) - $(date -d "30 minutes ago" +%s))) -lt $DURATION ]; do TIMESTAMP=$(date +%s) # 获取所有RegionServer的指标（需提前配置HBase REST API或JMX） for RS in $(hbase org.apache.hadoop.hbase.util.HBaseConfTool | grep "hbase.regionserver.hostname" | awk '{print $3}'); do # 示例：通过JMX获取MemStore大小（实际需替换为你的JMX URL） MEMSTORE=$(curl -s "http://$RS:16030/jmx?qry=Hadoop:service=HBase,name=RegionServer,sub=Metrics" | \ jq -r '.beans[0]."hbase.regionserver.memstore.size" // "0"') # BlockCache命中率（简化示例，实际需解析JSON） BC_HIT=$(curl -s "http://$RS:16030/jmx?qry=Hadoop:service=HBase,name=RegionServer,sub=Metrics" | \ jq -r '.beans[0]."hbase.regionserver.blockcache.hitRatio" // "0"') # WAL同步时间（毫秒） WAL_SYNC=$(curl -s "http://$RS:16030/jmx?qry=Hadoop:service=HBase,name=RegionServer,sub=Metrics" | \ jq -r '.beans[0]."hbase.regionserver.wal.syncTime.numOps" // "0"') # Compaction队列长度 COMPACT_Q=$(curl -s "http://$RS:16030/jmx?qry=Hadoop:service=HBase,name=RegionServer,sub=Metrics" | \ jq -r '.beans[0]."hbase.regionserver.compaction.queueLength" // "0"') echo "$TIMESTAMP,$RS,$MEMSTORE,$BC_HIT,$WAL_SYNC,$COMPACT_Q" >> $METRICS_FILE done sleep 10 done echo "Baseline collection completed. Results saved to $METRICS_FILE"

这段脚本不是拿来就跑的，它背后有三个关键设计逻辑：

• 压力模型真实：--randomRead=true模拟真实业务的随机Get，而非顺序Scan；--multiGet=10模拟客户端批量请求习惯；
• 指标采集精准：每10秒抓一次，避开瞬时毛刺，且指标与压力源严格时间对齐；
• 环境隔离干净：测试前disable/drop/create表，杜绝历史数据干扰。

我见过太多团队跳过这步，直接改hbase.hregion.max.filesize，结果发现“优化后”性能更差——因为原集群本身就有大量小文件，调大MaxFileSize只是让Compaction更难触发，小文件越积越多。

3.2 步骤二：RowKey设计重构——所有优化的起点与终点

HBase没有索引，RowKey就是唯一索引。90%的性能问题，根子都在RowKey。我把它总结为“三避三要”原则：

• 避单调递增：如timestamp、auto-increment id，导致所有写入打到同一个Region（Hotspot）；

• 避长字符串：如user_email，RowKey过长占用MemStore和HFile空间，降低缓存效率；

• 避业务强耦合：如order_status，状态变更需Put全量更新，引发大量WAL和MemStore压力。

• 要散列前置：hash(rowkey_part) % region_count，强制数据均匀分布；

• 要时间维度后置：hash(device_id) + timestamp，保证同一设备数据局部有序，利于Scan；

• 要精简可控：RowKey总长建议<100字节，只包含查询必需字段，其余放Column Family。

真实案例：某IoT平台设备上报表优化

原RowKey：device_id + "_" + timestamp（如dev_12345_1672531200000）
问题：device_id相同，所有上报集中到少数Region，单Region QPS超5万，MemStore频繁Flush，HFile小文件泛滥。

新RowKey设计：

// Java伪代码，实际用Phoenix或自定义协处理器实现 public static String buildRowKey(String deviceId, long timestamp) { // 1. 对deviceId取模，假设预分区20个Region int regionNum = Math.abs(deviceId.hashCode()) % 20; // 2. 将regionNum左填充为2位，保证字典序 String prefix = String.format("%02d", regionNum); // 3. 时间戳转为可读格式，但保证字典序（年月日时分秒） String timeStr = new SimpleDateFormat("yyyyMMddHHmmss").format(new Date(timestamp)); return prefix + "_" + deviceId.substring(0, Math.min(8, deviceId.length())) + "_" + timeStr; } // 示例：05_dev_12345678_20230101123045

效果对比（同硬件，同QPS压力）：

关键点：这不是“加盐”，而是“分片+截断+格式化”的组合拳。prefix保证分散，deviceId截断控制长度，timeStr格式化保证Scan时能利用时间范围过滤。很多教程只说“加hash”，却不说hash后如何保证业务查询（如查某设备最近10条），这就成了纸上谈兵。

3.3 步骤三：MemStore与WAL的协同调优——写入吞吐的生死线

MemStore是内存缓冲，WAL是磁盘保险，二者必须协同。调优核心就一句话：让MemStore尽可能多装、尽可能晚刷，但WAL必须能跟上这个节奏。否则，要么MemStore撑爆OOM，要么WAL写不过来导致写入阻塞。

关键参数与计算逻辑：

• hbase.hregion.memstore.flush.size（单Region MemStore大小阈值）：默认128MB。计算公式：
  合理值 = (单RegionServer可用堆内存 * 0.4) / 预期Region数
  例如：RegionServer堆内存32G，预估100个Region，则32*0.4/100 = 128MB，与默认值一致；若Region数只有20，则应调至640MB。

• hbase.regionserver.global.memstore.size（全局MemStore上限）：默认0.4。这是硬上限，一旦达到，所有写入被Reject。切勿盲目调高！正确做法是：先确保hbase.hregion.memstore.flush.size合理，再根据实际Flush频率微调此值。我们线上集群设为0.38，留2%余量防突发。

• hbase.wal.provider：必须设为filesystem（默认），禁用asyncfs（异步WAL）除非你确认磁盘IO绝对充足。asyncfs虽能提升吞吐，但崩溃恢复风险陡增，金融级系统严禁使用。

• hbase.wal.buffer.size：WAL写缓冲区，默认1MB。计算公式：
  合理值 = 单次Put平均大小 * 预期并发写线程数 * 2
  例如：平均Put 2KB，100并发，则2*100*2 = 400KB，设为512KB即可。设太大浪费内存，设太小导致WAL频繁sync。

实操验证：WAL写入能力压测

# 测试WAL写入极限，确认磁盘能否承受 hbase org.apache.hadoop.hbase.PerformanceEvaluation \ --rows=100000 \ --table=test_wal_stress \ --compress=NONE \ --valueSize=1024 \ --batchSize=100 \ --clients=50 \ --write=true \ --writeToWAL=true \ --multiPut=10

观察iostat -x 1中%util是否持续>95%，await是否>50ms。若超标，说明WAL磁盘是瓶颈，此时调大MemStore只会让问题更糟，必须升级磁盘或分离WAL目录到SSD。

3.4 步骤四：BlockCache分层与BloomFilter实战——读取性能的杠杆支点

BlockCache不是越大越好，而是要“分层+精准”。HBase 2.x后推荐BucketCache（堆外内存）+LruBlockCache（堆内）混合模式，但配置极易踩坑。

标准配置模板（24G堆内存RegionServer）：

<!-- hbase-site.xml --> <!-- 启用BucketCache，使用堆外内存 --> <property> <name>hbase.bucketcache.ioengine</name> <value>offheap</value> </property> <property> <name>hbase.bucketcache.size</name> <value>16384</value> <!-- 16GB，单位MB --> </property> <!-- LruBlockCache保留给元数据和小对象 --> <property> <name>hfile.block.cache.size</name> <value>0.1</value> <!-- 仅占堆内存10%，即2.4GB --> </property> <!-- 关键：关闭LruBlockCache的eviction，由BucketCache统一管理 --> <property> <name>hbase.lru.blockcache.evict.by.default</name> <value>false</value> </property>

为什么这样配？

• BucketCache用堆外内存，不参与JVM GC，避免大缓存引发长时间Stop-The-World；
• LruBlockCache只留2.4GB，专用于HFile的BlockIndex和BloomFilter，这些元数据访问极频繁，必须在堆内保证低延迟；
• evict.by.default=false防止两个Cache互相驱逐，造成缓存震荡。

BloomFilter开启与验证：

# 在表级别开启ROWCOL模式（最适合Get查询） hbase shell > disable 'risk_event_log' > alter 'risk_event_log', {NAME => 'cf', BLOOMFILTER => 'ROWCOL'} > enable 'risk_event_log' # 验证是否生效 hbase org.apache.hadoop.hbase.util.HFile -p -f hdfs://namenode:8020/hbase/data/default/risk_event_log/.../cf/... # 输出中应包含：bloomFilterType = ROWCOL, bloomFilterSize = 1048576

BloomFilter不是开关，而是精度游戏。ROWCOL模式对Get(row, cf, cq)最有效，但内存开销比ROW模式高3-5倍。我们线上用ROWCOL，因为风控查询90%是Get(device_id, 'cf', 'status')，必须精准过滤。若你的场景是Scan多，Get少，则用ROW模式更省内存。

3.5 步骤五：Compaction策略定制——告别“定时炸弹”式合并

Compaction是HBase的双刃剑：不做，小文件爆炸，读放大严重；做猛，IO打满，写入阻塞。HBase 2.x默认ExploringCompactionPolicy已比老版RatioBasedCompactionPolicy智能，但仍需定制。

我们的生产策略（针对写多读少的风控日志表）：

<!-- hbase-site.xml --> <!-- 启用日期分片Compaction，按天归档 --> <property> <name>hbase.hstore.date.tiered.compaction.window.hours</name> <value>24</value> </property> <!-- 小文件合并阈值提高，减少Minor Compaction频率 --> <property> <name>hbase.hstore.compaction.min</name> <value>3</value> </property> <property> <name>hbase.hstore.compaction.max</name> <value>10</value> </property> <!-- Major Compaction交由离线窗口执行 --> <property> <name>hbase.hregion.majorcompaction</name> <value>0</value> <!-- 关闭自动Major --> </property> <!-- 自定义脚本每日凌晨2点执行 --> <property> <name>hbase.hregion.majorcompaction.jitter</name> <value>0.5</value> </property>

配套自动化Major Compaction脚本（每日执行）：

#!/bin/bash # 文件名：daily_major_compact.sh # 功能：每日凌晨2点对指定表执行Major Compaction，避开业务高峰 TABLE_NAME="risk_event_log" DATE_STR=$(date -d "yesterday" +%Y%m%d) # 1. 检查昨日数据是否已完全写入（通过HDFS文件最后修改时间） YESTERDAY_HFILE=$(hadoop fs -ls /hbase/data/default/$TABLE_NAME/*/cf/ | \ grep "$DATE_STR" | tail -1 | awk '{print $8}') if [ -z "$YESTERDAY_HFILE" ]; then echo "No data for $DATE_STR found. Skipping compaction." exit 0 fi # 2. 执行Major Compaction（只针对昨日Region） echo "Starting major compaction for $DATE_STR..." hbase shell <<EOF major_compact '$TABLE_NAME', '$YESTERDAY_HFILE' EOF # 3. 清理过期HFile（保留7天） hadoop fs -rm -r /hbase/archive/data/default/$TABLE_NAME/*/cf/*.$(date -d "7 days ago" +%Y%m%d)*

核心思想：把Compaction从“在线扰动”变成“离线维护”。我们禁用自动Major，只在数据写入稳定后（次日凌晨）手动触发，且只针对已归档的日期分区。这样既保证HFile质量，又不伤业务。某次我们忘记关自动Major，结果凌晨3点Compaction占满IO，导致白天实时风控延迟飙升，教训深刻。

3.6 步骤六：Region预分区与动态分裂控制——让数据自己找家

Region是HBase的调度单元，数量太少，单点压力大；太多，ZK元数据膨胀，Master压力大。我们的黄金法则是：初始预分区数 = 集群RegionServer数 × 2~3，后续靠Split自动扩展，但必须限制分裂时机。

预分区脚本（创建表时执行）：

# 创建20个预分区，覆盖整个MD5哈希空间 hbase shell <<EOF create 'risk_event_log', {NAME => 'cf', TTL => 604800, COMPRESSION => 'SNAPPY'}, {SPLITS => [ '05', '0a', '0f', '14', '19', '1e', '23', '28', '2d', '32', '37', '3c', '41', '46', '4b', '50', '55', '5a', '5f', '64' ]} EOF

为什么选MD5前两位十六进制？因为hash(device_id) % 20的结果均匀分布在0-19，而00-64正好覆盖0-100的十六进制，20个Split点能完美对应20个Region。

动态分裂控制（防碎片化）：

<!-- hbase-site.xml --> <!-- 关闭自动Split，改用手动触发 --> <property> <name>hbase.hregion.majorcompaction</name> <value>0</value> </property> <property> <name>hbase.hregion.max.filesize</name> <value>2147483648</value> <!-- 2GB，比默认10GB小，防单Region过大 --> </property> <!-- 但允许手动Split --> <property> <name>hbase.hregion.split.policy</name> <value>org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy</value> </property>

实操心得：我们从不依赖自动Split。每天巡检脚本会扫描所有Region，对StoreFile size > 1.5GB且Requests per second > 5000的Region，执行split 'region_name'。这样既保证Region大小合理，又避免分裂发生在业务高峰期。

3.7 步骤七：ZK与Master高可用加固——让协调层不再拖后腿

最后一步，也是最容易被忽视的一步：协调层的稳定性。HBase再快，ZK一卡，全盘皆输。

ZK加固三项实操：

1. ZK集群独立部署：绝不与HBase共用节点，ZK三节点最小化，部署在SSD服务器上；
2. Session Timeout精准设置：zookeeper.session.timeout设为30000（30秒），zookeeper.zxid.precedence设为true，确保ZK Leader选举时序正确；
3. Master高可用：启用hbase.master.ha.enabled=true，配置hbase.master.maxclockskewms=30000，容忍时钟漂移。

Master GC优化（关键！）：
Master进程不处理数据，但元数据操作（如Assign、Unassign）全靠它。我们曾因Master JVM堆设为4G，CMS GC频繁，导致Region分配延迟超20秒。解决方案：

• 改用G1 GC，-XX:+UseG1GC -XX:MaxGCPauseMillis=200；
• 堆内存降至2G，-Xms2g -Xmx2g；
• 关键：hbase.master.meta.thread.rescan.interval从默认10秒改为30秒，降低元数据轮询频率。

验证Master健康度：

# 检查Master GC日志（需配置JVM参数输出GC log） grep "GC pause" /var/log/hbase/hbase-hbase-master-*.log | tail -10 # 检查Region分配延迟 echo "mntr" | nc master_host 2181 | grep "zk_avg_latency" # 应<5ms，>20ms则ZK或Master有问题

4. 常见问题与排查技巧实录：那些文档里不会写的“血泪经验”

4.1 问题一：RegionServer频繁OOM，但堆内存监控显示只用了60%

现象：RegionServer进程突然退出，日志报java.lang.OutOfMemoryError: Java heap space，但jstat -gc显示used才12G（堆32G）。

根因排查：
这不是Java堆问题，而是Direct Memory（堆外内存）溢出。HBase 2.x默认启用BucketCache，它使用-XX:MaxDirectMemorySize控制，而此参数默认等于-Xmx（32G）。当BucketCache设为16G，加上Netty的ByteBuf、HDFS的DFSClient缓冲区，很容易突破32G。

解决方案：

• 显式设置-XX:MaxDirectMemorySize=20g（略大于BucketCache）；
• 在hbase-env.sh中添加：

  export HBASE_REGIONSERVER_OPTS="$HBASE_REGIONSERVER_OPTS -XX:MaxDirectMemorySize=20g"

• 监控Direct Memory：jstat -gc -h10 <pid> 1000，关注CCSU（Compressed Class Space Used）和MU（Metaspace Used）之外的DC（Direct Count）和DU（Direct Used）。

实操心得：我们线上所有RegionServer都加了-XX:NativeMemoryTracking=detail，用jcmd <pid> VM.native_memory summary随时查看堆外内存分布。有一次发现Internal项占用15G，追查是HDFS客户端的DFSInputStream缓冲区泄漏，升级Hadoop版本解决。

4.2 问题二：HBase Shell执行list命令卡住30秒，但hbase hbck正常

现象：hbase shell里list、status等命令超时，但hbase hbck能快速返回，HBase Web UI也正常。

根因：hbase shell默认使用ZooKeeper连接，而hbck走RPC。卡住说明ZK客户端连接异常，但ZK服务本身OK。常见于：

• ZK客户端sessionTimeout设得太小，网络抖动导致频繁重连；
• hbase.zookeeper.quorum配置了多个ZK地址，但其中一台DNS解析慢，客户端按顺序尝试，卡在第一台。

解决方案：

• 在hbase-site.xml中显式设置