修改Linux最大文件数
Linux系统最大可打开文件数一般默认的参数值是1024,如果你不进行修改并发量上来的时候会出现“Too ManyOpen Files”的错误,
导致整个HBase不可运行
查看:ulimit -a 结果:open files(-n) 1024
临时修改:ulimit -n 4096
持久修改:
vi /etc/security/limits.conf在文件最后加上:
*soft nofile 65535
*hard nofile 65535
*soft nproc 65535
*hard nproc 65535
JVM调优:
regionserver默认内存大小为1G,memStore占比40%,
很小容易发生写阻塞 修改hbase-env.sh中的
# export HBASE_HEAPSIZE=1G(默认注释掉)
JDK版本低于8,HBase会有一个内存泄漏的Bug,永久对象区(Permanent Generation,这个区域在非堆内存里边)
export HBASE_MASTER_OPTS="$HBASE_MASTER_OPTS -xx:PermSize=128m -XX:MaxPermSize=128m"
export HBASE_REGIONsERVER_OPTS="$HBASE_REGIONSERVER_OPTS -xx:PermSize=128m -XX:MaxPermSize=128m"
如果xml调的比较大了,那么需要把PermSize和maxPermSize调整的都大一些
(一般不会出现这种情况,128M已经够大了)。JDK8+优化过,以后可以直接删除掉。
注:RegionServer的内存占有率一般是除去mr(计算框架)最大的
通常认为RegionServer的堆内存越大越好,但是因为GC的缘故,内存大了之后,
FullGC时间也会线性增加,FullGC可能长达几分钟,甚至会停止响应任何请求
,相当于所有线程挂起,这种暂停叫做STW(Stop-The-World),就会造成GC的卡顿。
在Zookeeper检测RegionServer心跳的时候,
RegionServer正在FullGc无法回应,而如果超过阈值的等待时间会被标记为宕机,
这时候会将该RegionServer上的数据向其他RegionServer迁移,
并且该RegionServer在FullGc结束后发现自己被Zookeeper判定为宕机了,
为了防止脑裂,会停止自己(RegionServer自杀,艺名朱丽叶暂停)。
原因主要是Zookeeper在RegionServer发生FULL GC的时候,由于STW期间太长,
被Zookeeper标记为宕机,当RegionerServer GC完成后,苏醒了发现被标记为宕机了,
这时候RegionerServer GC就自杀,防止脑裂发生。醒来怕脑裂就自杀,产生了朱丽叶暂停
直接的解决方法:
zookeeper的心跳检测阀值调大或者调大RegionServer的内存
不过这样解决的话,会增长时间,所以根据自己的选择来确定你的优化策略
JVM提供了四中GC回收器(避免长时间FullGC或者减少FullGc的发生):
串行回收器:SerialGC
并行回收器:ParallelGC 对年轻代进行优化 jdk8的默认策略 性能不是特别好 FullGC的时间较短,HBase中FullGC对于rs影响很大,所以一般选用并行回收器( 高吞吐量)
并发回收器:ConcMarkSweepGC 简称CMS 对老年代进行优化 减少老年代的暂停时间,可以保证应用不停止的情况下进行收集,缺点是会留下浮动垃圾,只能等待下次回收( 低延迟)
G1GC回收器:Garbage-First GC 吸收了并发和并行回收的特长 大内存(32GB以上)进行优化
参数调优
hregionserver的操作线程数
hbase.hregionserver.handle.count=30
region拆分策略:
(防止一个region过大)
(某些特定的环境(数据量突然增大,会导致region不停地合并拆分,设置为-1就是关掉)
0.94版本之前默认storefile达到10G,region进行拆分
0.94版本开始
#刷新阈值
hbase.hregion.memstore.flush.size默认为128M,
#切分阈值
hbase.hregion.max.filesize默认为10G.
两种自定义拆分策略
1、KeyPrefixRegionSplitPolicy策略,即根据rowkey指定长度的前缀来划分region
2、DelimitedKeyPrefixRegionSplitPolicy策略:保证以分隔符前面的前缀为splitPoint,保证相同RowKey前缀的数据在一个Region中。
minor compact
storefile达到数量后就进行和并
只是简单的将文件合并到一起,不做任何的删除更新操作
合并速度快,效率高
major compact
设置的定期的合并(压缩)
会进行数据的更新和删除操作,会耗费大量的磁盘IO
业务高峰期不会做这种操作
这种合并都是定期定时的执行
客户端优化
- 关闭自动刷新
ht.setAutoFlush(true,false)
- 尽量批量写入
- 谨慎关闭写hlog(已经存在的数据,出错了直接改就行的)
ht.setDurability(Durability.SKIP_WAL) - 尽量将数据放到缓存中
- 列族不要太多
- rowkey优化:
https://blog.youkuaiyun.com/qq_43755771/article/details/90720805 - 尽量关闭可关闭的对象