【功能模块】生产 c70集群  hbase模块【操作步骤&问题现象】同样的代码生产环境1、用java客户端get请求查询hbase，首次查询等待40s秒后出现超时，但接下后续查询就很正常，几十毫秒就可以查到结果2、但如果在上次成功查询后，两分钟后 再去get请求hbase，依旧等待40s后出现超时异常，后面的请求正常测试环境无超时情况，但是首次和间隔两分钟这种get请求，时间稍微久了点

使用MRS 3.0.5安装（包含了hbase组件），为何在master1上找不到hbase命令？参考文档：https://support.huaweicloud.com/cmpntguide-mrs/bakmrs_01_0368.html

请问，华为云 MRS 集群上的HBASE存储的数据如何做到落盘加密呢？ 我看购买MRS 2.1版本时有整盘加密选项，到MRS 3.0 这个选项就没有了。 搜华为文档，发现可以自行配置加密 https://support.huaweicloud.com/usermanual-mrs/admin_guide_000276.html， 但似乎又不推荐。那么今后华为MRS HBASE 落盘加密的规划是怎样的？ 是以后会支持整盘加密，还是支持用户通过配置HFile WAL加密？谢谢

各位老师，有没有遇到过这种问题，单独的hive可以查到数据，单独地hbase经过zk可以往hbase中put数据，但是连起来，先查hive，再把hive的结果，用hbase链接zk，往hbase中put数据，就报用户认证错误。具体保错如下图，请老师帮忙解决下，谢谢啦。 469221

问题分析  查看regionserver的运行日志(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.log)发现报错连接主机失败，原因是主机名后多了.localhost;2.  /etc/resolv.conf文件中多了一行search localhost。        问题解决参考    将/ect/resolv.conf文件中的search localhost注释掉重启服务恢复。

问题分析            查看regionserver的.out(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.out)日志发现重启是由于jvm crash。查看hs_err_pid.log日志，显示异常堆栈未0xb4。问题根因ARM服务器上，openjdk已知bug。简单来说，就是CMS代码中存在逻辑：1.load oop 2.load oop->class  3.load->class.field，这三步本身是需要包再时序的，但是事实上，在arm上由于弱内存续，实际的实行顺序有可能是2/3/1或者2/1/3，这样就没办法保证每一步取到的都是正确的数据，一旦取到的数据有问题，就可能被当作一个地址去做访问二，就SIGSEGV了。问题解决参考    不使用CMS算法。    

问题分析 排查regionserver运行日志（/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.log），异常重启的原因为连不上zookeeper集群。查看zookeeper GC日志与运行日志。发现zookeeper gc 日志中存在Full GC打印。问题解决参考    ZooKeeper实例Full GC导致RegionServer连不上zookeeper，需要增大ZooKeeper的GC配置。FI界面修改quorumpeer的GC配置如下，修改完后保存配置，重启zookeeper服务。

问题分析查看异常重启的regionserver的hbase.out(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.out)日志显示重启原因为jvm crash。查看对应hs_err_pid.log所有显示异常时堆栈再0x43。GC参数配置xmx 41G，表压缩算法ZSTD，两个条件共存时会导致RegionServer重启异常，其中一个不满足，不会触发该问题。问题解决参考    修改GC配置在31G以下或者将表的压缩算法改成其他的。

问题分析查看对应RegionServer运行日志(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.log)，报错在hdfs如下目录下找不到协处理器jar包。File does not exits:hdfs://hacluster/user/CORLU81NETMLB/bulkload/indexProcessor/Coprocessor.jarRegionServer协处理器jar包放置目录不对，导致RegionServer无法加载到协处理器异常重启。问题解决参考    disable使用这个协处理器的表，将协处理器放到对应的hdfs的目录下，重启RegionServer，重新enable表。

问题分析RS实例异常重启，regionserver运行日志(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.log)中报NullPointException异常：        2020-05-22 09:52:35,314 | FATAL | RpcServer.FifoWFPBQ.default.handler=208,queue=28,port=21302 | ABORTING region server fj-hadoop-hdp04,21302,1589247069521: The coprocessor org.apache.hadoop.hbase.regionserver.IndexHalfStoreFileReaderGenerator threw java.lang.NullPointerException | org.apache.hadoop.hbase.regionserver.HRegionServer.abort(HRegionServer.java:2256)        java.lang.NullPointerException         at java.util.ArrayList.addAll(ArrayList.java:581)         at org.apache.hadoop.hbase.regionserver.IndexHalfStoreFileReaderGenerator.getLocalIndexScanners(IndexHalfStoreFileReaderGenerator.java:375)         at org.apache.hadoop.hbase.regionserver.IndexHalfStoreFileReaderGenerator.access$000(IndexHalfStoreFileReaderGenerator.java:71)         at org.apache.hadoop.hbase.regionserver.IndexHalfStoreFileReaderGenerator$1.getScannersNoCompaction(IndexHalfStoreFileReaderGenerator.java:321)         at org.apache.hadoop.hbase.regionserver.StoreScanner.<init>(StoreScanner.java:212)         at org.apache.hadoop.hbase.regionserver.IndexHalfStoreFileReaderGenerator$1.<init>(IndexHalfStoreFileReaderGenerator.java:316)         at org.apache.hadoop.hbase.regionserver.IndexHalfStoreFileReaderGenerator.preStoreScannerOpen(IndexHalfStoreFileReaderGenerator.java:315)         at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$59.call(RegionCoprocessorHost.java:1424)         at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost$RegionOperation.call(RegionCoprocessorHost.java:1780)         at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperation(RegionCoprocessorHost.java:1856)         at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.execOperationWithResult(RegionCoprocessorHost.java:1819)         at org.apache.hadoop.hbase.regionserver.RegionCoprocessorHost.preStoreScannerOpen(RegionCoprocessorHost.java:1419)         at org.apache.hadoop.hbase.regionserver.HStore.getScanner(HStore.java:2154)         at org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.initializeScanners(HRegion.java:5980)         at org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.<init>(HRegion.java:5954)         at org.apache.hadoop.hbase.regionserver.HRegion$RegionScannerImpl.<init>(HRegion.java:5959)         at org.apache.hadoop.hbase.regionserver.HRegion.instantiateRegionScanner(HRegion.java:2768)         at org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:2748)         at org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:2730)         at org.apache.hadoop.hbase.regionserver.HRegion.getScanner(HRegion.java:2724)         at org.apache.hadoop.hbase.regionserver.RSRpcServices.newRegionScanner(RSRpcServices.java:2742)         at org.apache.hadoop.hbase.regionserver.RSRpcServices.scan(RSRpcServices.java:3000)         at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$2.callBlockingMethod(ClientProtos.java:35072)         at org.apache.hadoop.hbase.ipc.RpcServer.call(RpcServer.java:2482)         at org.apache.hadoop.hbase.ipc.CallRunner.run(CallRunner.java:123)         at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:191)         at org.apache.hadoop.hbase.ipc.RpcExecutor$Handler.run(RpcExecutor.java:168)    2. 此问题为开源问题，单号为：https://issues.apache.org/jira/browse/PHOENIX-4839    3. 原因是在PHOENIX-4885以后，any local index query will open all HFiles of every Region，所以在本地索引查询的时候会打开所有的hfile去查询，有一些storescanner在memstore中存储，所以要去内存中扫描，但是根据pt没有找到对应的storescanner，返回为null。此处将null加入到了arraylist中，报了空指针异常。问题解决参考    6.5.1.7版本已经解决，升级版本到6.5.1.7。

问题分析      根据regionserver运行日志发现RS与zk之间的session连接超时达到172s，正常情况下，regionserver与zookeeper之间的心跳连接超时时间为90s，如果超过90s，zookeeper没有收到regionserver的心跳连接，zookeeper会认为zookeeper发生了异常，会将regionserver重启，与客户确认发现客户环境将regionserver的GC内存配置为64G，导致每次GC时间特别久；修改HBase服务端参数zookeeper.session.timeout和zk 服务端 的maxSessionTimeout增大到15min，观察几天没有出现regionserve重启问题。问题解决参考   调小GC配置为31G。增大HBase服务端参数zookeeper.session.timeout和zk 服务端参数maxSessionTimeout。

问题分析查看发生异常重启regionserver运行日志(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.log)查找重启的原因，发现是写WALs超过5min触发了regionserver的重启保护机制。查看该regionserver运行日志的slow sync cost的时间，发现耗时都非常长,slow sync cost耗时长一般都是由于dn的性能慢（写磁盘慢或者网络慢导致）。使用grep "write data to disk" hadoop-omm-datanode-DSJ-FS-FI-0620.2020-09-24_08-23-56.\[1\].log| grep "2020-09-24 04:5"命令查看对应时刻是否有写磁盘慢的打印。使用grep "Slow flushOrSync" hadoop-omm-datanode-DSJ-FS-FI-0620.2020-09-24_08-23-56.\[1\].log| grep "2020-09-24 04:5"命令查看对应时刻是否有磁盘刷盘慢的打印。FlushOrsync耗时长意味着存在慢盘或者磁盘坏道较多的盘。需要进一步排查磁盘。问题解决参考      慢盘或者磁盘坏道导致写wal卡住，更换磁盘。

问题分析检查RegionServer运行日志(/var/log/BigData/hbase/rs/hbase-omm-regionserver-xxx.log)，其中报错该节点与HMaster节点的时间差大于30s；具体报错如下:Master rejected startup because clock is out of sync| org.apache.hadoop.hbase.regionserver.HRegionServer.reportForDutyorg.apache.hadoop.hbase.ClockOutOfSyncException:org.apache.hadoop.hbase.ClockOutOfSyncException:Server hdfs02,21302,xxxx has been rejectd;Reported time is too far out of sync with master.Time difference of 88759ms >max allowed of 30000ms检查异常重启regionserver节点的NTP服务状态，NTP一直是初始化的状态；检查/etc/ntp.conf文件配置异常，与其他节点不一致，从正常其他regionserver节点拷贝/etc/ntp.conf文件到本节点后重启NTP服务后，NTP状态恢复正常；等时间同步后重启实例，恢复正常。问题解决参考       NTP服务异常导致RegionServer节点时间与HMaster节点时间差超过30s，从而导致RegionServer重启，恢复NTP服务，重启RegionServer实例。

问题分析查看regionserver运行日志(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.log)，发现regionserver重启时间在11.49；查看该异常节点的nodeagent日志(/var/log/Bigdata/nodeagent/agentlog/agent.log)，11:49分之前健康检查多次超时；查看异常节点的hbase 实例检查日志（/var/log/Bigdata/hbase/rs/checkServiceDetail.log），大部分检查都没打印出success，说明实例检查时间超时，上一次健康检查时间过长，本次健康检查删除上一次健康检查pid文件；查看hbase.log（（/var/log/Bigdata/hbase/rs/hbase.log），健康检查时间超过了4分钟和5分钟，超过了nodeagent调用的超时脚本；问题根因在于 regionserver处理健康检查请求超过了4分钟，分析regionserver的GC日志(/var/log/Bigdata/hbase/rs/regionserver-omm-xxx-pidxxx-gc.log.x.current)，使用的是g1算法；gc 日志证明内存使用达到40G，regionserver处理时延时较高，占用内存的原因为，tagramzone表列未合并，导致查询性能下降handler被使用完。问题解决参考           Tagamzone表列未合并，如果没有开启异步合并，那就会进行同步合并，开启了，但是如果创建表的参数不对，也会不合并也会有问题，该问题为未开启异步合并导致查询处理性能下降 handler被使用完，需业务侧进行整改。具体需要如下2步骤配合使用，如下所示：服务端修改如下tagram.tagzone.dynamitag.async.compact为true代码中进行如下设置：

如题，我们想验证下HBase的性能，请问用哪种工具比较好？