hbase的优化的一点经验,一直没做这个笔记,是因为hbase自身也有设计缺陷,所以有些配置不能说优化,只能说因为hbase自身缺陷可以将就着用,不说废话了,以下就是优化的一点笔记
hbase配置修改:
(split是因为hfile过多,进行split,split之后进行compact
可以可能要有人喷了,hfile多了应该compact才对啦。贴出0.98.1的代码,大致逻辑是region没有block的compact(优先级大于等于1的),则进行split)
private boolean flushRegion(final FlushRegionEntry fqe) { HRegion region = fqe.region; if (!region.getRegionInfo().isMetaRegion() && isTooManyStoreFiles(region)) {//这个函数使用了参数 if (fqe.isMaximumWait(this.blockingWaitTime)) { LOG.info("Waited " + (System.currentTimeMillis() - fqe.createTime) + "ms on a compaction to clean up 'too many store files'; waited " + "long enough... proceeding with flush of " + region.getRegionNameAsString()); } else { // If this is first time we've been put off, then emit a log message. if (fqe.getRequeueCount() <= 0) { // Note: We don't impose blockingStoreFiles constraint on meta regions LOG.warn("Region " + region.getRegionNameAsString() + " has too many " + "store files; delaying flush up to " + this.blockingWaitTime + "ms"); if (!this.server.compactSplitThread.requestSplit(region)) {//这里是关键的逻辑,逻辑是region没有block的compact(优先级大于等于1的),则进行split;否则进行compact try { this.server.compactSplitThread.requestSystemCompaction( region, Thread.currentThread().getName()); } catch (IOException e) { LOG.error( "Cache flush failed for region " + Bytes.toStringBinary(region.getRegionName()), RemoteExceptionHandler.checkIOException(e)); } } } // Put back on the queue. Have it come back out of the queue // after a delay of this.blockingWaitTime / 100 ms. this.flushQueue.add(fqe.requeue(this.blockingWaitTime / 100)); // Tell a lie, it's not flushed but it's ok return true; } } return flushRegion(region, false); }
hbase.hstore.blockingStoreFiles hfile数量上限,如果超过,则进行阻塞写,进行split | compact
hbase.hstore.blockingWaitTime 阻塞写的时间上限 ,到时间没进行split或compact(就是没锁上,则继续)
最大region 500G,禁止常规的split情况
<property>
<name>hbase.hregion.max.filesize</name>
<value>536870912000</value>
</property>
一个store中30个hfile的上限
<property>
<name>hbase.hstore.blockingStoreFiles</name>
<value>30</value>
</property>
一分半的写的阻塞上限
<property>
<name>hbase.hstore.blockingWaitTime</name>
<value>90000</value>
</property>
hbase.regionserver.regionSplitLimit region包含的最大region数, split需要检查现有region不大于这个
compact Priority逻辑
初始化为int.minvalue,user为1,被block>1
-----------------------------------------------
DEBUG [LruStats #0] hfile.LruBlockCache: Total=11.78 GB, free=1.01 GB, max=12.79 GB,
memcache设置256
memcache使用mslb
使用mslb
<property>
<name>hbase.hregion.memstore.mslab.enabled</name>
<value>true</value>
</property>
memcash的flush的条件256M
<property>
<name>hbase.hregion.memstore.flush.size</name>
<value>268435456</value>
</property>
安全检查memstore使用region_heap的百分比 , 强制flush
</property>
base.regionserver.global.memstore.lowerLimit
<property>
<name>hbase.regionserver.global.memstore.lowerLimit</name>
<value>0.36</value>
<description>
一个RS中所有的memstore的总容量超过堆的该百分比限制后,将被强制flush到磁盘。
Maximum size of all memstores in a region server before flushes are forced. Defaults to 35% of heap. 这个值与
hbase.regionserver.global.memstore.upperLimit相等,以减小由于到达该值触发flush的几率,因为这种flush会block写请求
</description>
</property>
安全检查memstore使用region_heap的百分比 , 强制flush,并阻塞写请求
<property>
<name>hbase.regionserver.global.memstore.upperLimit</name>
<value>0.4</value>
<description>
一个region中所有memstore的总大小超过堆的该百分比限制时,会发生强制flush,并block更新请求。
默认是堆大小的40%。更新会被阻塞,并发生强制flush,直到所有memstore的大小达到
hbase.regionserver.global.memstore.lowerLimit的限制。
</description>
</property>
达到flushsize指定倍数时,会强制flush,并阻塞请求
<property>
<name>hbase.hregion.memstore.block.multiplier</name>
<value>2</value>
<description>
当一个region的memstore达到hbase.hregion.memstore.block.multiplier * hbase.hregion.flush.size的指定倍数时,阻塞写请求。
这是一个避免在写请求高峰时期避免memstore耗尽的有效设置。如果没有上限限制,memstore被填满后发生flush时,
会消耗大量的时间来处理合并和分割,甚至导致OOM。
</description>
</property>
----------------------------------------------------
gc的问题
3.5分钟挂掉
11 分钟
(70)提前gc,减少每个gc耗时
hbase-env.sh中
export HBASE_REGIONSERVER_OPTS="-Xmx16g -Xms16g -Xmn128m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=70 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:$HBASE_HOME/logs/gc-hbase.log"
----------------------------------------------------
compact时间是否过长??
compact的时候gc过长
2015-02-25 11:54:50,670 WARN [regionserver60020.periodicFlusher] util.Sleeper: We slept 565427ms instead of 10000ms, this is likely due to a long garbage collecting pause and it's usually bad, se
e http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired
2015-02-25 11:54:50,670 WARN [DataStreamer for file /hbase/WALs/host64,60020,1422073827259/host64%2C60020%2C1422073827259.1424835178059 block BP-1540478979-192.168.5.117-1409220943611:blk_1097821
214_24084365] hdfs.DFSClient: Error Recovery for block BP-1540478979-192.168.5.117-1409220943611:blk_1097821214_24084365 in pipeline 192.168.5.64:50010, 192.168.5.95:50010: bad datanode 192.168.5.
64:50010
2015-02-25 11:54:50,670 WARN [regionserver60020.compactionChecker] util.Sleeper: We slept 565427ms instead of 10000ms, this is likely due to a long garbage collecting pause and it's usually bad,
see http://hbase.apache.org/book.html#trouble.rs.runtime.zkexpired
2015-02-25 11:54:50,670 INFO [regionserver60020-SendThread(host141:42181)] zookeeper.ClientCnxn: Client session timed out, have not heard from server in 577669ms for sessionid 0x44add78c8664fdb,
closing socket connection and attempting reconnect
转为手动compact,需要逐步手动compact
<property>
<name>hbase.hregion.majorcompaction</name>
<value>0</value>
</property>
------------------------------------------------------
regionserver里的handler数量 50
<property>
<name>hbase.regionserver.handler.count</name>
<value>50</value>
<source>hbase-site.xml</source>
</property>
--------------------------------------------------
wal大小,影响memcash flush
当前hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs 128*32=4G
但是hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE 0.38*32=12.16G
hbase.regionserver.global.memstore.upperLimit * HBASE_HEAPSIZE 0.4*32=12.8
注意:确保hbase.regionserver.hlog.blocksize * hbase.regionserver.maxlogs 比hbase.regionserver.global.memstore.lowerLimit * HBASE_HEAPSIZE的值只高那么一点点。.
改为
<property>
<name>hbase.regionserver.maxlogs</name>
<value>104</value>
</property>
<property>
<name>hbase.regionserver.global.memstore.lowerLimit</name>
<value>0.36</value>
</property>
128*105=13G
0.36*32=11.52G
0.4*32=12.8G
原则是让memflush不阻塞,禁止因为wal触发的flush,wal会进行多region flush,并且阻塞,这是最坏的情况
---------------------------------------------------
blockcache是读取时使用内存
<property> <name>hfile.block.cache.size</name> <value>0.4</value> </property>
----------------------------------------------------
超时时间待验证,设置或过长
<property> <name>hbase.rowlock.wait.duration</name> <value>90000</value> <description> 每次获取行锁的超时时间,默认为30s </description> </property> <property> <name>hbase.regionserver.lease.period</name> <value>180000</value> <description> 客户端每次获得rs一次socket时间 </description> </property> <property> <name>hbase.rpc.timeout</name> <value>180000</value> <description> rpc超时时间 </description> </property> <property> <name>hbase.client.scanner.timeout.period</name> <value>180000</value> <description> 客户端每次scan|get的超时时间 </description> </property> <property> <name>hbase.client.scanner.caching</name> <value>100</value> <description> 客户端每次scan的一个next,获得多少行,默认1 </description> </property>
相关推荐
以下是对"**Hbase配置所需要的配置文件.zip**"中可能包含的配置文件及其作用的详细解释: 1. **hbase-site.xml**: 这是HBase的主要配置文件,包含了HBase集群的全局配置参数。例如,你可以在这里设置`hbase.rootdir...
——HBase性能优化 1、从配置角度优化 1.1 修改Linux配置 Linux系统最大可打开文件数一般默认的参数值是1024,如果你不进行修改并发量上来的时候会出现“Too Many Open Files”的错误,导致整个HBase不可运行,你...
二、配置优化 1. **Region大小调整**:根据数据量和访问模式调整Region大小,避免热点Region和过于分散的Region。 2. **Column Family设计**:合理规划列族,避免过多列族导致的元数据开销,同时根据访问模式设置...
3. **HBase配置调整**:例如增大`hbase.hregion.max.filesize`以控制Region大小,调整`hbase.regionserver.handler.count`以增加处理线程数,或者优化`hbase.hregion.memstore.flush.size`以平衡内存和磁盘IO。...
除了上述提到的优化方法,HBase的性能优化还可以涉及更多的方面,如合理调整HBase配置、分区和负载均衡策略、压缩和存储优化、监控和诊断等。在HBase集群中,还可能通过调整HMaster和HRegionServer的相关参数来...
在"HBase配置文件若干配置.zip"中,我们可能找到了与这些配置相关的模板或修改建议。 首先,`hbase.rootdir`是HBase的数据目录,它定义了HDFS上的路径,用于存储HBase的所有表数据和元数据。例如,可以设置为`hdfs:...
6. **性能调优**:涵盖JVM参数、HBase配置、硬件选择、数据分布策略等方面的优化技巧。 7. **监控和故障排查**:如何通过HBase的仪表盘和日志进行监控,以及在遇到问题时的排查方法。 8. **复制和备份**:HBase...
hbase优化总结 HBase 是一个基于列存储的 NoSQL 数据库,广泛应用于...HBase 的优化需要从多方面考虑,包括 Linux 系统、JVM 配置、HBase 配置等方面。通过合理的调整,可以提高 HBase 的性能,满足实际应用的需求。
本文将探讨一种新的方法——基于机器学习的HBase配置参数优化研究,其主要目的就是解决这一难题。 在引入机器学习技术之前,传统的优化方法主要依靠人工经验来调整HBase配置。然而,随着数据量的激增以及应用场景的...
9-1 Zookeeper安装与HBase配置优化 9-2 Hos开发逻辑梳理 9-3 Hos模块划分及mybatis配置 第10章 子模块-用户管理模块 Hos服务用户管理模块开发,基于第九章的数据库操作模块,开发相关的实体类对用户的增删改查操作...
在HBase性能优化的过程中,表设计和RowKey的设计是至关重要的。预分区是表设计的一个重要环节,目的是避免因表的自动split导致的资源消耗和性能影响。预分区可以根据业务需求预先设定rowkey的范围,比如在例子中,...
1. **HBase配置文件** HBase的配置主要通过`hbase-site.xml`文件进行,此文件位于`$HBASE_HOME/conf`目录下。在这个XML文件中,你可以设置各种系统参数,如Zookeeper地址、HBase的根目录等。 2. **Zookeeper配置**...
- **HBase配置优化**:重点介绍对HBase配置的优化方法。 - **ZooKeeper优化**:说明如何优化ZooKeeper以提升性能。 - **Schema设计优化**:给出优化Schema设计的具体建议。 - **写入优化**:介绍如何优化写入操作。 ...
合理地进行优化配置,需要深入理解HBase的工作机制和数据存储模型,同时结合实际应用场景和业务需求,对各个参数进行微调,以达到最优的读取性能。在生产环境中,这种优化往往需要反复测试和调整,以实现系统性能的...
4. **垃圾回收(GC)问题**:通过调整JVM参数和HBase配置优化GC行为。 通过以上分析可以看出,HBase不仅是一个高效的分布式存储系统,而且在处理大规模数据集方面具有独特的优势。正确地理解和应用HBase的各项功能,...
通过这份详尽的配置文件集合,你可以快速搭建起一个基本的Hadoop和HBase环境,并根据实际工作负载进行优化。记住,每个参数的调整都可能影响到系统的性能、可用性和扩展性,因此在调整时要谨慎行事。
这份“HBase配置项说明及调优建议”资料,旨在帮助用户理解HBase的核心配置参数,并提供实用的优化策略。 首先,我们要了解HBase的几个关键配置类别: 1. **Master节点配置**:Master节点负责管理表和Region的分配...
在搭建Hadoop框架中的HBase集群之前,理解并熟悉HBase的配置文件是至关重要的步骤。HBase是一款基于Google Bigtable理念设计的开源分布式数据库,它构建于Hadoop之上,适用于处理海量数据。HBase提供了高可靠性、高...
### HBase性能优化知识点汇总 #### HDFS优化 - **存储机制**: HBase使用HDFS存储WAL(Write-Ahead Log)和HFiles。默认情况下,HDFS不会实时同步数据到磁盘,而是写入临时文件后移动到最终位置,导致在断电情况下...
│ Hbase性能优化-配置snappy压缩 │ Hbase中索引的介绍 │ PHoenix的编译及安装部署 │ PHoenix与Hbase表的关联使用 ├─03_笔记 │ [案例:Hbase的设计及企业优化].txt ├─04_代码 │ └─微博案例 ├─08_作业 ...