1、巡检

HBase 是使用 HDFS 作为底层存储的 NoSQL 数据库，提供了满足实时性和随即读写功能的数据库服务。

每日早晚巡检 HBase 服务，检查各集群的 HMaster 和 RegionServer 状态，是否事务积压等问题。

1.1、查看CM HBase 的整体状态

1.HBase 的状态，目前看没有严重警告

2.查看集群读写请求量

3.查看总 Region 数，有 4 万+的 Region

平均每个 RegionServer 有 1000+的 region，已经比较高了，有风险

4.Master 状态查看，GC 时候有点高

5.查看单个 RegionServer 情况

1.2、查看备用HMaster

每个库正常来说都有 3 个主节点，一个正在跑，两个备用，如图所示。

1.3、查看Requests Per Second 和 Num. Regions

若为图中所示为 0，则需要登录主机查看，通常这种情况会发生在重启节点主机后发生

1.4、查看Software Attributes

图中所示，比较重要的是两个标出部分：

1：代表着本库的 zookeeper 节点，如果出现异常，总数会不正常的

2：代表着本库的平均 region 数，理论超过 300 就要进行合并操作的，但这个是根据业务的需求进行操作，业务侧提出数据库卡顿了，再进行合并操作即可

1.5、查看Dead Region ServeRegionServer

登录 HBase UI，若有 HBaseregionserver 宕掉的节点，则页面上会显示出如下情况：

出现这种情况，则说明有非正常节点，可以尝试登陆该故障节点，查看故障原因（如 HBase 进程消失，主机意外重启，主机死机等）

2、参数调优

2.1、Region 相关参数

hbase.hregion.max.filesize

默认 10G，Region 中任意 HStore 所有文件大小总和大于该值就会进行分裂。实际生产环境中该值不建议太大，也不能太小，太大会导致系统后台执行 compaction 消耗大量系统资源，一定程度上影响业务响应；太小会导致

Region 分裂比较频繁，分裂本身其实对业务读写会有一定影响，使单个RegionServer 中存在大量 Region，太多 Region 会消耗大量维护资源，并且在 RegionServer 下线迁移时比较耗时。建议线上设置为 50G～80G 左右。

2.2、BlockCache 相关参数

BlockCache 相关的参数非常多，不同 BlockCache 策略对应不同的参数，RegionServer 内存在 20G 以内的就选择 LRUBlockCache，大于 20G 的就选择 BucketCache 中的 Offheap 模式。

BucketCache 的 offheap 模式配置：

file.block.cache.size：默认 0.4，该值用来设置 LRUBlockCache 的内存大小，0.4 表示JVM 内存的 40%，当前HBase 系统默认采用LRUBlockCache策略，BlockCache 大小和 Memstore 大小均为 JVM 的 40%。但对于

BucketCache 策略来讲，Cache 分为了两层，L1 采用 LRUBlockCache，主要存储 HFile 中的元数据 Block，L2 采用 BucketCache，主要存储业务数据Block。因为只用来存储元数据 Block，所以只需要设置很小的 Cache 即可。建议线上设置为 0.05～0.1 左右。

hbase.bucketcache.ioengine：offheap

hbase.bucketcache.size：堆外存大小，设置多大就看自己的物理内存大小了

2.3、刷写参数

HBase 写入数据时会先写 WAL 日志，再将数据写到写缓存 MemStore 中，等写缓存达到一定规模或其他触发条件时会 Flush 刷写到磁盘，生成一个 HFile 文件，这样就将磁盘随机写变成了顺序写，提高了写性能。

随着时间推移，写入的 HFile 会越来越多，读取数据时就会因为要进行多次 io 导致性能降低，因此 HBase 会定期执行 Compaction 操作以合并减少HFile 数量，提升读性能。

触发条件和参数

有 7 种情况会触发 Flush：

1)当一个 MemStore 大小达到阈值hbase.hregion.memstore.flush.size（默认128M）时，会触发MemStore 的刷写，此时不会阻塞写请求。

2)当一个 Region 中所有 MemStore 总大小达到hbase.hregion.memstore.block.multiplier * hbase.hregion.memstore.flush.size （ 默认 4*128M=512M ） 时， 会触发 MemStore 的刷写， 并阻塞 Region 所有的写请求， 此时写数据会出现 RegionTooBusyException 异常。

3)当一个 RegionServer 中所有 MemStore 总大小达到hbase.regionserver.global.memstore.size.lower.limit* hbase.reg ionserver.global.memstore.size * hbase_heapsize（ 低水位阈值，默认 0.95 * 0.4 * RS 堆大小） 时， 会触发 RegionServer 中内存占用大的 MemStore 的刷写； 达到hbase.regionserver.global.memstore.size * hbase_heapsize （ 高水位阈值， 默认 0.4 * RS 堆大小） 时， 不仅会触发 Memstore 的刷写，还会阻塞 RegionServer 所有的写请求，直到 Memstore  总大小降到低水位阈值以下。

4)当一个 RegionServer 的 HLog 即 WAL 文件数量达到上限（ 可通过参数 hbase.regionserver.maxlogs 配置， 默认 32） 时， 也会触发MemStore 的 刷 写 ， HBase 会 找 到 最 旧 的 HLog 文 件 对 应 的Region 进行刷写 。

5)当一个 Region 的更新次数达到hbase.regionserver.flush.per.changes（ 默认 30000000 即 3 千万） 时， 也会触发 MemStore 的刷写。

6)定期 hbase.regionserver.optionalcacheflushinterval（ 默认3600000 即一个小时）进行 MemStore 的刷写，确保 MemStore  不会长时间没有持久化。 为避免所有的 MemStore 在同一时间进行flush 而导致问题， 定期的 flush 操作会有一定时间的随机延时。

7)手动执行 flush 操作，我们可以通过 hbase shell 或 API 对一张表或一个 Region 进行 flush。

上面是 Flush 的几个触发条件，5 个和  Flush  有关的重要参数及调整建议：

hbase.hregion.memstore.flush.size

默认值 128M， 单个 MemStore 大小超过该阈值就会触发  Flush。如果当前集群 Flush 比较频繁，并且内存资源比较充裕，建议适当调整为 256M。调大的副作用可能是造成宕机时需要分裂的 HLog 数量变多， 从而延长故障恢复时间。

hbase.hregion.memstore.block.multiplier

默认值 4，Region 中所有 MemStore  超过单个 MemStore 大小的倍数达到该参数值时， 就会阻塞写请求并强制 Flush。一般不建议调整， 但对于写入过快且内存充裕的场景， 为避免写阻塞， 可以适当调整到 5~8。

hbase.regionserver.global.memstore.size

默 认 值   0.4 ， RegionServer  中 所 有   MemStore  大 小 总 和 最 多占 RegionServer 堆内存的 40%。这是写缓存的总比例，可以根据实际场景适当调整，且要与 HBase 读缓存参数 hfile.block.cache.size（ 默 认  也  是  0.4  ）  配  合  调  整  。  旧  版  本  参  数  名  称为 hbase.regionserver.global.memstore.upperLimit。

hbase.regionserver.global.memstore.size.lower.limit

默认值 0.95，表示 RegionServer 中所有 MemStore  大小的低水位是 hbase.regionserver.global.memstore.size 的  95%， 超过该比例 就 会 强 制  Flush 。 一 般 不 建 议 调 整 。 旧 版 本 参 数 名 称为 hbase.regionserver.global.memstore.lowerLimit。

hbase.regionserver.optionalcacheflushinterval

默 认 值 3600000 （ 即 1 小 时 ） ， HBase 定 期 Flush 所 有MemStore 的时间间隔。一般建议调大，比如 10 小时，因为很多场景下 1 小时 Flush  一次会产生很多小文件， 一方面导致  Flush  比较频繁， 另一方面导致小文件很多， 影响随机读性能， 因此建议设置较大值。

\

2.4、合并相关参数

HBase 会定期执行 Compaction 合并 HFile，提升读性能，其实就是以短时间内的 io 消耗， 换取相对稳定的读取性能。

Compaction 类型分为两种： Minor Compaction 与 Major Compaction， 可以称为小合并、大合并， 简单示意图：

Minor Compaction 是指选取一些小的、相邻的 HFile 将他们合并成一个更大的   HFile，Minor Compaction  会删除选取   HFile  中的 TTL 过期数据。

Major Compaction 是指将一个 Store 中所有的  HFile  合并成一个 HFile， 这个过程会清理三类没有意义的数据： 被删除的数据（ 打了 Delete 标记的数据）、TTL 过期数据、版本号超过设定版本号的数据。另外， 一般情况下， Major Compaction 时间会持续比较长， 整个过程会消耗大量系统资源， 对上层业务有比较大的影响。因此， 生产环境下通常关闭自动触发 Major Compaction 功能， 改为手动在业务低峰期触发。

Compaction 触发时机

HBase 会在三种情况下检查是否要触发 Compaction， 分别是MemStore Flush、后台线程周期性检查、手动触发。

1)MemStore Flush： 可以说 Compaction 的根源就在于 Flush，MemStore 达到一定阈值或触发条件就会执行 Flush 操作，在磁盘上生成 HFile 文件，正是因为 HFile 文件越来越多才需要 Compact。HBase 每次 Flush 之后， 都会判断是否要进行  Compaction， 一旦满足 Minor Compaction  或  Major Compaction  的条件便会触发执行。

2)后台线程周期性检查： 后台线程 CompactionChecker  会定期检查 是 否 需 要 执 行 Compaction ， 检 查 周 期 为hbase.server.thread.wakefrequency * hbase.server.compactchecker.interval.multiplier ， 这里主要考虑的是一段时间内没有写入仍然需要做 Compact 检查。 其中参数hbase.server.thread.wakefrequency 默认值 10000 即 10s ， 是HBase 服 务 端 线 程 唤 醒 时 间 间 隔 ， 用 于 LogRoller 、MemStoreFlusher 等的周期性检查； 参数hbase.server.compactchecker.interval.multiplier 默认值 1000 ， 是 Compaction 操作周期性检查乘数因子， 10 * 1000 s 时间上约等于 2hrs, 46mins, 40sec 。

3)手动触发： 通过 HBase Shell、Master UI 界面或 HBase API 等任一种方式执行 compact 、 major_compact 等命令， 会立即触发Compaction

Compaction 核心参数

1)hbase.hstore.compaction.min

默认值 3，一个 Store 中 HFile 文件数量超过该阈值就会触发一次 Minor Compaction，这里称该参数为 minFilesToCompact。一般不建议调小，重写场景下可以调大该参数，比如 5~10 之间。老版本参数名称为hbase.hstore.compactionthreshold。

2)hbase.hstore.compaction.max

默认值 10，一次 Minor Compaction 最多合并的 HFile 文件数量，这里称该参数为 maxFilesToCompact。这个参数也控制着一次压缩的耗时。一般不建议调整，但如果上一个参数调整了，该参数也应该相应调整，一般设为 minFilesToCompact 的 2~3 倍 。

3)hbase.regionserver.thread.compaction.throttle

评估单个 compaction 为 small 或者 large 的判断依据。为了防止 large compaction 长时间执行阻塞其他 small compaction，hbase 将这两种compaction 进行了分离处理，每种 compaction 会分配独立的线程池HBase RegionServer 内部设计了两个线程池 large compactions 与 small compactions，用来分离处理 Compaction 操作，该参数就是控制一个Compaction 交由哪一个线程池处理，默认值是 2 * maxFilesToCompact hbase.hregion.memstore.flush.size（默认 210*128M=2560M 即 2.5G）， 建议不调整或稍微调大。

4)hbase.regionserver.thread.compaction.large/small

默认值 1，表示 large compactions 与 small compactions 线程池的大小。一般建议调整到 2~5，不建议再调太大比如 10，否则可能会消费过多的服务端资源造成不良影响。

5)hbase.hstore.blockingStoreFiles

默认值 10，表示一个 Store 中 HFile 文件数量达到该值就会阻塞写入，等待 Compaction 的完成。一般建议调大点，比如设置为 100，避免出现阻塞更新的情况，阻塞日志如下：

too many store files; delaying flush up to 90000ms

生产环境建议认真根据实际业务量做好集群规模评估，如果小集群遇到了持续写入过快的场景，合理扩展集群也非常重要。

6)hbase.hregion.majorcompaction

默认值 604800000 ms 即 7 天，这是 Major Compaction 周期性触发执行的时间间隔。通常 Major Compaction 持续时间较长、资源消耗较大，一般设为 0，表示关闭自动触发，建议在业务低峰期时手动执行。

2.5、HLog 相关参数

1)hbase.regionserver.maxlogs

默认为 32，region flush 的触发条件之一，wal 日志文件总数超过该阈值就会强制执行 flush 操作。该默认值对于很多集群来说太小，生产线上具体设置参考 HBASE-14951

2)hbase.regionserver.hlog.splitlog.writer.threads

默认为 3，regionserver 恢复数据时日志按照 region 切分之后写入 buffer， 重新写入 hdfs 的线程数。生产环境因为 region 个数普遍较多，为了加速数据恢复，建议设置为 10。

2.6、Call Queue 相关参数

1)hbase.regionserver.handler.count

默认为 30，服务器端用来处理用户请求的线程数。生产线上通常需要将该值调到 100～200。

解读：response time = queue time + service time，用户关心的请求响应时间由两部分构成，优化系统需要经常关注 queue time，如果用户请求排队时间很长，首要关注的问题就是 hbase.regionserver.handler.count 是否没有调整。

2)hbase.ipc.server.callqueue.handler.factor

默认为 0，服务器端设置队列个数，假如该值为 0.1，那么服务器就会设置handler.count * 0.1 = 30 * 0.1 = 3 个队列。

3)hbase.ipc.server.callqueue.read.ratio

默认为 0，服务器端设置读写业务分别占用的队列百分比以及 handler 百分比。假如该值为 0.5，表示读写各占一半队列，同时各占一半 handler。

2.7、其他参数

1)hbase.online.schema.update.enable

默认为 false，表示更新表 schema 的时候不再需要先 disable 再 enable，直接在线更新。该参数在 HBase 2.0 之后将会默认为 true。生产线上建议设置为true。

2)hbase.quota.enabled

默认为 false，表示是否开启 quota 功能，quota 功能主要用来限制用户/表的QPS，起到限流作用。生产线上建议设置为 true。

3)hbase.snapshot.enabled

默认为 false，表示是否开启 snapshot 功能，snapshot 功能主要用来备份HBase 数据。生产线上建议设置为 true。

4)zookeeper.session.timeout

默认 180s，表示 zookeeper 客户端与服务器端 session 超时时间，超时之后RegionServer 将会被踢出集群。

解读：有两点需要重点关注，其一是该值需要与 Zookeeper 服务器端 session 相关参数一同设置才会生效，一味的将该值增大而不修改 ZK 服务端参数，可能并不会实际生效。其二是通常情况下离线集群可以将该值设置较大，在线业务需要根据业务对延迟的容忍度考虑设置。

5)hbase.zookeeper.useMulti

默认为 false，表示是否开启 zookeeper 的 multi-update 功能，该功能在某些场景下可以加速批量请求完成，而且可以有效防止部分异常问题。生产线上建议设置为 true。注意设置为 true 的前提是 Zookeeper 服务端的版本在 3.4 以上，否则会出现 zk 客户端夯住的情况。

3、运维

3.1、扩容

同HDFS扩容

3.2、退役

1）CM 操作退役：

2）命令行操作退役：

bin/graceful_stop.sh hadoop1

然后关闭 regionserver

hbase-daemon.sh stop regionserver 启动平衡

hbase> balance_switch truebin/graceful_stop.sh hadoop1

3.3、预分区

3.3.1、分区过多的影响

1.频繁刷写

Region 的一个列族对应一个 MemStore，假设 HBase 表都有统一的 1 个列族配置，则每个 Region 只包含一个 MemStore。通常 HBase 的一个MemStore 默认大小为 128 MB，见参数hbase.hregion.memstore.flush.size。当可用内存足够时，每个 MemStore 可以分配 128 MB 空间。当可用内存紧张时，假设每个 Region 写入压力相同， 则理论上每个 MemStore 会平均分配可用内存空间。

因此，当节点 Region 过多时，每个 MemStore 分到的内存空间就会很小。这个时候，写入很小的数据量就会被强制 Flush 到磁盘，将会导致频繁刷写。频繁刷写磁盘，会对集群 HBase 与 HDFS 造成很大的压力，可能会导致不可预期的严重后果。

2.压缩风暴

因 Region 过多导致的频繁刷写，将在磁盘上产生非常多的 HFile 小文件， 当小文件过多的时候 HBase 为了优化查询性能就会做 Compaction 操作，合并 HFile 减少文件数量。当小文件一直很多的时候，就会出现 "压缩风暴"。

Compaction 非常消耗系统 io 资源，还会降低数据写入的速度，严重的会影响正常业务的进行。

3.MSLAB 内存消耗较大

MSLAB（MemStore-local allocation buffer）存在于每个 MemStore 中，主要是为了解决 HBase 内存碎片问题，默认会分配 2 MB 的空间用于缓存最新数据。如果 Region 数量过多，MSLAB 总的空间占用就会比较大。比如当前节点有 1000 个包含 1 个列族的 Region，MSLAB 就会使用 1.95GB 的堆内存，即使没有数据写入也会消耗这么多内存。

4.Master Assign Region 时间较长

HBase Region 过多时 Master 分配 Region 的时间将会很长。特别体现在重启 HBase 时 Region 上线时间较长，严重的会达到小时级，造成业务长时间等待的后果。

5.影响 MapReduce 并发数

当使用 MapReduce 操作 HBase 时，通常 Region 数量就是 MapReduce 的任务数，Region 数量过多会导致并发数过多，产生过多的任务。任务太多将会占用大量资源，当操作包含很多 Region 的大表时，占用过多资源会影响其他任务的执行。

计算分区合理的数量：

通常情况下每个节点拥有 20200 个 Region 是比较正常，每个RegionServer 的最大 Region 数量由总的 MemStore 内存大小决定，每个Region 的每个列族对应一个 MemStore，假设 HBase 表都有统一的 1 个列族配置，那么每个 Region 只包含一个 MemStore，一个 MemStore 大小通常在 128256 MB，见参数 hbase.hregion.memstore.flush.size。默认情况下，

RegionServer 会将自身堆内存的 40%（见参数hbase.regionserver.global.memstore.size）供给节点上所有 MemStore 使用，如果所有 MemStore 的总大小达到该配置大小，新的更新将会被阻塞并且会强制刷写磁盘。因此，每个节点最理想的 Region 数量应该由以下公式计算（假设 HBase 表都有统一的列族配置）：

Region.nums = ((RegionServer memory) * (total memstore fraction)) / ((memstore size)*(column families))

其中：

RegionServer memory：表示 regionserver 堆内存大小，即HBASE_HEAPSIZE。

total memstore fraction：表示所有 MemStore 占 HBASE_HEAPSIZE 的比例，HBase0.98 版本以后由 hbase.regionserver.global.memstore.size 参数控制，老版本由 hbase.regionserver.global.memstore.upperLimit 参数控制，默认值 0.4。

memstore size：即每个 MemStore 的大小，原生 HBase 中默认 128M。column families：即表的列族数量，通常情况下只设置 1 个，最多不超过 3 个。

假如一个集群中每个 RegionServer 的堆内存是 32GB，那么节点上最理想的 Region 数量应该是 32768*0.4/128 ≈ 102，所以，当前环境中单节点理想情况下大概有 102 个 Region。

这种最理想情况是假设每个 Region 上的填充率都一样，包括数据写入的频次、写入数据的大小，但实际上每个 Region 的负载各不相同，可能有的Region 特别活跃负载特别高，有的 Region 则比较空闲。所以，通常我们认为23 倍的理想 Region 数量也是比较合理的，针对上面举例来说，大概200300 个 Region 算是合理的。

如果实际的Region 数量比23 倍的计算值还要多，就要实际观察Region 的刷写、压缩情况了，Region 越多则风险越大，如果单节点 Region 数量过千， 集群可能存在较大风险， 在生产环境中，如果一个 regionserver 节点的Region 数量在 20200 我们认为是比较正常的，但是我们也要重点参考理论合理计算值。如果每个 Region 的负载比较均衡，分区数量在 2~3 倍的理论合理计算值通常认为也是比较正常的。

3.4、定位数据热点

查看 regionsever 的请求状态

查看表 region 的请求状态

3.5、开启 MSLAB 功能

为了减少内存碎片化，改善 Full GC 发生的情况，MemStore 会在内部维护一个 2M 大小的 Chunk 数组，当写入数据时会先申请 2M 的 Chunk， 将实际数据写入该 Chunk 中，当该 Chunk 满了以后会再申请一个新的Chunk。这样 MemStore Flush 后会达到粗粒度化的内存碎片效果，可以有效降低 Full GC 的触发频率。

HBase 默认是开启 MSLAB 功能的，和 MSLAB 相关的配置包括：

hbase.hregion.memstore.mslab.enabled：MSLAB 开关，默认为 true

hbase.hregion.memstore.mslab.chunksize：每个 Chunk 的大 小，默认为2MB，建议保持默认值。

hbase.hregion.memstore.chunkpool.maxsize：内部 Chunk Pool 功能， 默认为 0 ，即关闭 Chunk Pool 功能。设置为大于 0 的值才能开启，取值范围为 [0,1]，表示 Chunk Pool 占整个 MemStore 内存大小的比例。

hbase.hregion.memstore.chunkpool.initialsize：表示初始化时申请多少个Chunk 放到 Chunk Pool 中，默认为 0，即初始化时不申请 Chuck，只在写入数据时才申请。

hbase.hregion.memstore.mslab.max.allocation：表示能放入 MSLAB 的最大单元格大小，默认为 256KB，超过该大小的数据将从 JVM 堆分配空间而不是 MSLAB。

3.6、开启BucketCache

BlockCache 是 RegionServer 级别的，一个 RegionServer 只有一个BlockCache。BlockCache 的工作原理是读请求会首先检查 Block 是否存在于 BlockCache，存在就直接返回，如果不存在再去 HFile 和 MemStore 中获取，返回数据时把 Block 缓存到 BlockCache 中，后续同一请求或临近查询可以直接从 BlockCache 中获取，避免过多的昂贵 IO 操作。BlockCache 默认是开启的。

目前Block Cache 的实现方案有三种：

(1)LRUBlockCache

最早的 BlockCache 方案，也是 HBase 目前默认的方案。LRU 是 Least Recently Used 的缩写，称为近期最少使用算法。LRUBlockCache 参考了JVM 分代设计的思想，采用了缓存分层设计。

LRUBlockCache 将整个 BlockCache 分为 single-access（单次读取区）、multi-access（多次读取区）和 in-memory 三部分，默认分别占读缓存的25%、50%、25%。其中设置 IN_MEMORY=true 的列族，Block 被读取后才会直接放到 in-memory 区，因此建议只给那些数据量少且访问频繁的列族设置 IN_MEMORY 属性。另外，HBase 元数据比如 meta 表、namespace 表也都缓存在 in-memory 区。

(2)SlabCache

HBase 0.92 版本引入的一种方案，起初是为了避免 Full GC 而引入的一种堆外内存方案，并与 LRUBlockCache 搭配使用，后来发现它对 Full GC 的改善很小，以至于这个方案基本被弃用了。

(3)BucketCache

HBase 0.96 版本引入的一种方案，它借鉴了 SlabCache 的设计思想，是一种非常高效的缓存方案。实际应用中，HBase 将 BucketCache 和LRUBlockCache 搭配使用，称为组合模式（CombinedBlockCahce），具体地说就是把不同类型的 Block 分别放到 LRUBlockCache 和 BucketCache 中。

HBase 会 把 Index Block 和 Bloom Block 放 到 LRUBlockCache 中 ， 将Data Block 放到 BucketCache 中，所以读取数据会去 LRUBlockCache 查询一下 Index Block，然后再去 BucketCache 中查询真正的数据。

BucketCache 涉及的常用参数有：

hbase.bucketcache.ioengine：(配置此值即开启 BucketCache )使用的存储介质，可设置为 heap、offheap 或 file，其中 heap 表示空间从 JVM 堆中申请，offheap 表示使用 DirectByteBuffer 技术实现堆外内存管理，file 表示使用类似 SSD 等存储介质缓存数据。默认值为空，即关闭 BucketCache， 一般建议开启 BucketCache。此外，HBase 2.x 不再支持 heap 选型。

hbase.bucketcache.size：BucketCache 大小，取值有两种，一种是[0,1]之间的浮点数值，表示占总内存的百分比，另一种是大于 1 的值，表示占用内存大小，单位 MB。

3.7、禁用大合并

由于 Major 合并执行期间会对整个集群的磁盘和带宽带来较大影响，一般建议设置 hbase.hregion.majorcompaction 设为 0 来禁用该功能，并在夜间集群负载较低时通过定时任务脚本来执行。

3.8、手动触发大合并

合并 t1 表中所有的 region  

hbase> major_compact 't1'

合并 t1 表中的某个列族

hbase> major_compact 'r1', 'c1'

3.9、手动触发Flush

hbase> flush 't1'

4、排障

4.1、HBase 库连接数过多造成库堵塞的解决办法

【现象】

库现象：HBase 库节点正常，查看 web 页面一切正常，只有连接数变为 0，

【处理】

在主节点上运行 netstat -aoe 查看主机端口运行状态，可以看到有很多的CLOSE_WAIT，

这里可以看到服务器出现了大量的 CLOSE_WAIT， 修 改 /etc/sysctl.conf 配 置 文 件 ：  

net.ipv4.tcp_keepalive_time = 30

net.ipv4.tcp_keepalive_probes = 2

net.ipv4.tcp_keepalive_intvl = 2

使用 sysctl -p 使配置生效

然后会发现会出现大量的 TIME_WAIT 的连接 还要再修改下 linux 的

/etc/sysctl.conf 配置在最后加入

net.ipv4.tcp_fin_timeout = 30

net.ipv4.tcp_keepalive_time = 1200

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.ip_local_port_range = 1024 65000

net.ipv4.tcp_max_syn_backlog = 8192

net.ipv4.tcp_max_tw_buckets = 5000

net.ipv4.route.gc_timeout = 100

net.ipv4.tcp_syn_retries = 1

net.ipv4.tcp_synack_retries = 1

说 明 ： net.ipv4.tcp_syncookies = 1

表示开启 SYN Cookies。当出现 SYN 等待队列溢出时，启用 cookies 来处理， 可防范少量 SYN 攻击，默认为 0，表示关闭；

net.ipv4.tcp_tw_reuse = 1

表示开启重用。允许将 TIME-WAIT sockets 重新用于新的 TCP 连接，默认为0，表示关闭；

net.ipv4.tcp_tw_recycle = 1

表示开启 TCP 连接中 TIME-WAIT sockets 的快速回收，默认为 0，表示关闭。

net.ipv4.tcp_fin_timeout = 30

表示如果套接字由本端要求关闭，这个参数决定了它保持在 FIN-WAIT-2 状态的时间。

net.ipv4.tcp_keepalive_time = 1200

表示当 keepalive 起用的时候，TCP 发送 keepalive 消息的频度。缺省是 2 小时，改为 20 分钟。

net.ipv4.ip_local_port_range = 1024 65000

表示用于向外连接的端口范围。缺省情况下很小：32768 到 61000，改为 1024 到 65000。

net.ipv4.tcp_max_syn_backlog = 8192

表示 SYN 队列的长度，默认为 1024，加大队列长度为 8192，可以容纳更多等待连接的网络连接数。

net.ipv4.tcp_max_tw_buckets = 5000

表示系统同时保持 TIME_WAIT 套接字的最大数量，如果超过这个数字，TIME_WAIT 套接字将立刻被清除并打印警告信息。默认为 180000，改为5000。对于 Apache、Nginx 等服务器，上几行的参数可以很好地减少TIME_WAIT 套接字数量，但是对于 Squid，效果却不大。此项参数可以控制TIME_WAIT 套接字的最大数量，避免 Squid 服务器被大量的 TIME_WAIT 套接字拖死。

net.ipv4.route.gc_timeout = 100

路由缓存刷新频率， 当一个路由失败后多长时间跳到另一个默认是 300

net.ipv4.tcp_syn_retries = 1

对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃。不应该大于 255，默认值是 5，对应于 180 秒左右。

修改完成后等待一段时间，打开 web 界面会发现连接数已经正常，表示连接恢复正常

注：连接数过多，造成服务器堵塞一般情况下有两个原因造成：

1，网络不正常

2，业务哪里有问题，调用了接口而没有释放

所以一般情况下遇到这种情况首先找业务排查，如果他那没有问题，在按照上面的方法修改配置文件处理

4.2、业务侧无法正常入库解决方法

【排查】

1.登录对应HBase UI查看是否有RIT积压

2库HBase UI：10.162.xxx:60010/master-stat…

4库HBaseUI：10.162.xxx:60010/master-stat…

【处理】

如出现上图的标志（Regions in Transition），且数量较大，即可确定为有RIT 积压情况，需要重启HBase库，重启后刷新HBase UI，观察RIT数量，直到RIT 消失为止，即可通知业务测试入库情况

4.3、有Dead regionserver 解决方法

1.登录对应HBase UI，查看是否有Dead regionserver情况

2.如有上图所示情况，则说明该库有丢失regionserver节点，可以尝试ssh该主机，查看是否宕机或进程被踢掉

3.登录丢失节点主机后，jps查看对应进程，若没有HRegionServer进程，表示进程由于负载过大被踢出，需要手动重启该进程

4.输入命令：hbase-daemon.sh start regionserver

5.重新刷新HBase UI，若Dead regionserver消失，则表示成功