当前位置: 澳门新濠3559 > 编程 > 正文

1、hbase参数配置,写入请求会被拒绝

时间:2019-10-13 08:39来源:编程
首先我们简单回顾下整个写入流程 client api == RPC == server IPC == RPC queue == RPC handler == write WAL == write memstore == flush to filesystem 整个写入流程从客户端调用API开始,数据会通过protobuf编码成一

首先我们简单回顾下整个写入流程

client api ==> RPC ==>  server IPC ==> RPC queue ==> RPC handler ==> write WAL ==> write memstore ==> flush to  filesystem

整个写入流程从客户端调用API开始,数据会通过protobuf编码成一个请求,通过scoket实现的IPC模块被送达server的RPC队列中。最后由负责处理RPC的handler取出请求完成写入操作。写入会先写WAL文件,然后再写一份到内存中,也就是memstore模块,当满足条件时,memstore才会被flush到底层文件系统,形成HFile。


一、服务端调优

1、hbase参数配置
配置文件:hbase-site.xml和hbase.tmp.dir
(1)本地文件系统tmp目录,一般配置成local模式的设置一下,但是最好还是需要设置一下,因为很多文件都会默认设置成它下面的:
线上配置

当写入过快时会遇见什么问题?

写入过快时,memstore的水位会马上被推高。
你可能会看到以下类似日志:

RegionTooBusyException: Above memstore limit, regionName=xxxxx ...

这个是Region的memstore占用内存大小超过正常的4倍,这时候会抛异常,写入请求会被拒绝,客户端开始重试请求。当达到128M的时候会触发flush memstore,当达到128M * 4还没法触发flush时候会抛异常来拒绝写入。两个相关参数的默认值如下:

hbase.hregion.memstore.flush.size=128M
hbase.hregion.memstore.block.multiplier=4

或者这样的日志:

regionserver.MemStoreFlusher: Blocking updates on hbase.example.host.com,16020,1522286703886: the global memstore size 1.3 G is >= than blocking 1.3 G size
regionserver.MemStoreFlusher: Memstore is above high water mark and block 528ms

这是所有region的memstore内存总和开销超过配置上限,默认是配置heap的40%,这会导致写入被阻塞。目的是等待flush的线程把内存里的数据flush下去,否则继续允许写入memestore会把内存写爆

hbase.regionserver.global.memstore.upperLimit=0.4  # 较旧版本,新版本兼容
hbase.regionserver.global.memstore.size=0.4 # 新版本

当写入被阻塞,队列会开始积压,如果运气不好最后会导致OOM,你可能会发现JVM由于OOM crash或者看到如下类似日志:

ipc.RpcServer: /192.168.x.x:16020 is unable to read call parameter from client 10.47.x.x
java.lang.OutOfMemoryError: Java heap space

HBase这里我认为有个很不好的设计,捕获了OOM异常却没有终止进程。这时候进程可能已经没法正常运行下去了,你还会在日志里发现很多其它线程也抛OOM异常。比如stop可能根本stop不了,RS可能会处于一种僵死状态。


 1、参数配置

hbase.tmp.dir
/mnt/dfs/11/hbase/hbase-tmp

如何避免RS OOM?

一种是加快flush速度:

hbase.hstore.blockingWaitTime = 90000 ms
hbase.hstore.flusher.count = 2
hbase.hstore.blockingStoreFiles = 10

当达到hbase.hstore.blockingStoreFiles配置上限时,会导致flush阻塞等到compaction工作完成。阻塞时间是hbase.hstore.blockingWaitTime,可以改小这个时间。hbase.hstore.flusher.count可以根据机器型号去配置,可惜这个数量不会根据写压力去动态调整,配多了,非导入数据多场景也没用,改配置还得重启。

同样的道理,如果flush加快,意味这compaction也要跟上,不然文件会越来越多,这样scan性能会下降,开销也会增大。

hbase.regionserver.thread.compaction.small = 1
hbase.regionserver.thread.compaction.large = 1

增加compaction线程会增加CPU和带宽开销,可能会影响正常的请求。如果不是导入数据,一般而言是够了。好在这个配置在云HBase内是可以动态调整的,不需要重启。

   1)、hbase.regionserver.handler.count:该设置决定了处理RPC的线程数量,默认值是10,通常可以调大,比如:150,当请求内容很大(上MB,比如大的put、使用缓存的scans)的时候,如果该值设置过大则会占用过多的内存,导致频繁的GC,或者出现OutOfMemory,因此该值不是越大越好。

默认值:
java.io.tmpdir/hbase−

上述配置都需要人工干预,如果干预不及时server可能已经OOM了,这时候有没有更好的控制方法?
hbase.ipc.server.max.callqueue.size = 1024 * 1024 * 1024 # 1G

直接限制队列堆积的大小。当堆积到一定程度后,事实上后面的请求等不到server端处理完,可能客户端先超时了。并且一直堆积下去会导致OOM,1G的默认配置需要相对大内存的型号。当达到queue上限,客户端会收到CallQueueTooBigException 然后自动重试。通过这个可以防止写入过快时候把server端写爆,有一定反压作用。线上使用这个在一些小型号稳定性控制上效果不错。

阅读原文

 

{user.name}
写到系统的/tmp目录
hbase.rootdir

  2)、hbase.hregion.max.filesize 配置region大小,0.94.12版本默认是10G,region的大小与集群支持的总数据量有关系,如果总数据量小,则单个region太大,不利于并行的数据处理,如果集群需支持的总数据量比较大,region太小,则会导致region的个数过多,导致region的管理等成本过高,如果一个RS配置的磁盘总量为3T*12=36T数据量,数据复制3份,则一台RS服务器可以存储10T的数据,如果每个region最大为10G,则最多1000个region,如此看,94.12的这个默认配置还是比较合适的,不过如果要自己管理split,则应该调大该值,并且在建表时规划好region数量和rowkey设计,进行region预建,做到一定时间内,每个region的数据大小在一定的数据量之下,当发现有大的region,或者需要对整个表进行region扩充时再进行split操作,一般提供在线服务的hbase集群均会弃用hbase的自动split,转而自己管理split。

HBase集群中所有RegionServer共享目录,用来持久化HBase的数据,一般设置的是hdfs的文件目录,如hdfs://namenode.example.org:9000/hbase
线上配置

 

hbase.rootdir
hdfs://mycluster/hbase

  3)、hbase.hregion.majorcompaction:配置major合并的间隔时间,默认为1天,可设置为0,禁止自动的major合并,可手动或者通过脚本定期进行major合并,有两种compact:minor和major,minor通常会把数个小的相邻的storeFile合并成一个大的storeFile,minor不会删除标示为删除的数据和过期的数据,major会删除需删除的数据,major合并之后,一个store只有一个storeFile文件,会对store的所有数据进行重写,有较大的性能消耗。

默认值:
${hbase.tmp.dir}/hbase
hbase.cluster.distributed

 

集群的模式,分布式还是单机模式,如果设置成false的话,HBase进程和Zookeeper进程在同一个JVM进程。
线上配置为true
默认值:false
hbase.zookeeper.quorum

  4)、hbase.hstore.compactionThreshold:HStore的storeFile数量>= compactionThreshold配置的值,则可能会进行compact,默认值为3,可以调大,比如设置为6,在定期的major compact中进行剩下文件的合并。

zookeeper集群的URL配置,多个host中间用逗号(,)分割
线上配置

  5)、 hbase.hstore.blockingStoreFiles:HStore的storeFile的文件数大于配置值,则在flush memstore前先进行split或者compact,除非超过hbase.hstore.blockingWaitTime配置的时间,默认为7,可调大,比如:100,避免memstore不及时flush,当写入量大时,触发memstore的block,从而阻塞写操作。

hbase.zookeeper.quorum inspurXXX.xxx.xxx.org,inspurXXX.xxx.xxx.org,inspurXXX.xxx.xxx.org,inspurXXX.xxx.xxx.org,inspurXXX.xxx.xxx.org

 

默认值:localhost
hbase.zookeeper.property.dataDir

  6)、hbase.regionserver.global.memstore.upperLimit:默认值0.4,RS所有memstore占用内存在总内存中的upper比例,当达到该值,则会从整个RS中找出最需要flush的region进行flush,直到总内存比例降至该数限制以下,并且在降至限制比例以下前将阻塞所有的写memstore的操作,在以写为主的集群中,可以调大该配置项,不建议太大,因为block cache和memstore cache的总大小不会超过0.8,而且不建议这两个cache的大小总和达到或者接近0.8,避免OOM,在偏向写的业务时,可配置为0.45,memstore.lowerLimit保持0.35不变,在偏向读的业务中,可调低为0.35,同时memstore.lowerLimit调低为0.3,或者再向下0.05个点,不能太低,除非只有很小的写入操作,如果是兼顾读写,则采用默认值即可。

ZooKeeper的zoo.conf中的配置。 快照的存储位置
线上配置:/home/hadoop/zookeeperData
默认值:${hbase.tmp.dir}/zookeeper
zookeeper.session.timeout

 

客户端与zk连接超时时间
线上配置:1200000(20min)
默认值:180000(3min)
hbase.zookeeper.property.tickTime

  7)、hbase.regionserver.global.memstore.lowerLimit:默认值0.35,RS的所有memstore占用内存在总内存中的lower比例,当达到该值,则会从整个RS中找出最需要flush的region进行flush,配置时需结合memstore.upperLimit和block cache的配置。

Client端与zk发送心跳的时间间隔
线上配置:6000(6s)
默认值:6000
hbase.security.authentication

 

HBase集群安全认证机制,目前的版本只支持kerberos安全认证。
线上配置:kerberos
默认值:空
hbase.security.authorization

  8)、file.block.cache.size:RS的block cache的内存大小限制,默认值0.25,在偏向读的业务中,可以适当调大该值,具体配置时需试hbase集群服务的业务特征,结合memstore的内存占比进行综合考虑。

HBase是否开启安全授权机制
线上配置: true
默认值: false
hbase.regionserver.kerberos.principal

 

regionserver的kerberos认证的主体名称(由三部分组成:服务或用户名称、实例名称以及域名)
线上配置:hbase/_HOST@HADOOP.xxx.xxx.COM
1、hbase参数配置,写入请求会被拒绝。默认:无
hbase.regionserver.keytab.file

  9)、hbase.hregion.memstore.flush.size:默认值128M,单位字节,超过将被flush到hdfs,该值比较适中,一般不需要调整。

regionserver keytab文件路径
线上配置:/home/hadoop/etc/conf/hbase.keytab
默认值:无
hbase.master.kerberos.principal

 

master的kerberos认证的主体名称(由三部分组成:服务或用户名称、实例名称以及域名)
线上配置:hbase/_HOST@HADOOP.xxx.xxx.COM
默认:无
hbase.master.keytab.file

  10)、hbase.hregion.memstore.block.multiplier:默认值2,如果memstore的内存大小已经超过了hbase.hregion.memstore.flush.size的2倍,则会阻塞memstore的写操作,直到降至该值以下,为避免发生阻塞,最好调大该值,比如:4,不可太大,如果太大,则会增大导致整个RS的memstore内存超过memstore.upperLimit限制的可能性,进而增大阻塞整个RS的写的几率。如果region发生了阻塞会导致大量的线程被阻塞在到该region上,从而其它region的线程数会下降,影响整体的RS服务能力,例如:

master keytab文件路径
线上配置:/home/hadoop/etc/conf/hbase.keytab
默认值:无
hbase.regionserver.handler.count

开始阻塞:

regionserver处理IO请求的线程数
线上配置:50
默认配置:10
hbase.regionserver.global.memstore.upperLimit

图片 1 
 解开阻塞: 
图片 2 
 从10分11秒开始阻塞到10分20秒解开,总耗时9秒,在这9秒中无法写入,并且这期间可能会占用大量的RS handler线程,用于其它region或者操作的线程数会逐渐减少,从而影响到整体的性能,也可以通过异步写,并限制写的速度,避免出现阻塞。

RegionServer进程block进行flush触发条件:该节点上所有region的memstore之和达到upperLimit*heapsize
线上配置:0.45
默认配置:0.4
hbase.regionserver.global.memstore.lowerLimit

 

RegionServer进程触发flush的一个条件:该节点上所有region的memstore之和达到lowerLimit*heapsize
线上配置:0.4
默认配置:0.35
hbase.client.write.buffer

  11)、hfile.block.index.cacheonwrite:在index写入的时候允许put无根(non-root)的多级索引块到block cache里,默认是false,设置为true,或许读性能更好,但是是否有副作用还需调查。

客户端写buffer,设置autoFlush为false时,当客户端写满buffer才flush
线上配置:8388608(8M)
默认配置:2097152(2M)
hbase.hregion.max.filesize

 

单个ColumnFamily的region大小,若按照ConstantSizeRegionSplitPolicy策略,超过设置的该值则自动split
线上配置:107374182400(100G)
默认配置:21474836480(20G)
hbase.hregion.memstore.block.multiplier

  12)、io.storefile.bloom.cacheonwrite:默认为false,需调查其作用。

超过memstore大小的倍数达到该值则block所有写入请求,自我保护
线上配置:8(内存够大可以适当调大一些,出现这种情况需要客户端做调整)
默认配置:2
hbase.hregion.memstore.flush.size

 

memstore大小,当达到该值则会flush到外存设备
线上配置:104857600(100M)
默认值: 134217728(128M)
hbase.hregion.memstore.mslab.enabled

  13)、hbase.regionserver.regionSplitLimit:控制最大的region数量,超过则不可以进行split操作,默认是Integer.MAX,可设置为1,禁止自动的split,通过人工,或者写脚本在集群空闲时执行。如果不禁止自动的split,则当region大小超过hbase.hregion.max.filesize时会触发split操作(具体的split有一定的策略,不仅仅通过该参数控制,前期的split会考虑region数据量和memstore大小),每次flush或者compact之后,regionserver都会检查是否需要Split,split会先下线老region再上线split后的region,该过程会很快,但是会存在两个问题:1、老region下线后,新region上线前client访问会失败,在重试过程中会成功但是如果是提供实时服务的系统则响应时长会增加;2、split后的compact是一个比较耗资源的动作。

是否开启mslab方案,减少因内存碎片导致的Full GC,提高整体性能
线上配置:true
默认配置: true
hbase.regionserver.maxlogs

 

regionserver的hlog数量
线上配置:128
默认配置:32
hbase.regionserver.hlog.blocksize

  14)、Jvm调整:

hlog大小上限,达到该值则block,进行roll掉
线上配置:536870912(512M)
默认配置:hdfs配置的block大小
hbase.hstore.compaction.min

       a、内存大小:master默认为1G,可增加到2G,regionserver默认1G,可调大到10G,或者更大,zk并不耗资源,可以不用调整;

进入minor compact队列的storefiles最小个数
线上配置:10
默认配置:3
hbase.hstore.compaction.max

   b、垃圾回收:待研究。

单次minor compact最多的文件个数
线上配置:30
默认配置:10
hbase.hstore.blockingStoreFiles

 

当某一个region的storefile个数达到该值则block写入,等待compact
线上配置:100(生产环境可以设置得很大)
默认配置: 7
hbase.hstore.blockingWaitTime

2、其它调优

block的等待时间
线上配置:90000(90s)
默认配置:90000(90s)
hbase.hregion.majorcompaction

  1)、列族、rowkey要尽量短,每个cell值均会存储一次列族名称和rowkey,甚至列名称也要尽量短,以下截图是表test2的数据和存入hdfs后的文件内容: 
图片 3 
  
图片 4 
 由上图可见:短的列族名称、rowkey、列名称对最终的文件内容大小影响很大。

触发major compact的周期
线上配置:0(关掉major compact)
默认配置:86400000(1d)
hbase.regionserver.thread.compaction.large

 

large compact线程池的线程个数
线上配置:5
默认配置:1
hbase.regionserver.thread.compaction.small

  2)、RS的region数量:一般每个RegionServer不要过1000,过多的region会导致产生较多的小文件,从而导致更多的compact,当有大量的超过5G的region并且RS总region数达到1000时,应该考虑扩容。

small compact线程池的线程个数
线上配置:5
默认配置:1
hbase.regionserver.thread.compaction.throttle

 

compact(major和minor)请求进入large和small compact线程池的临界点
线上配置:10737418240(10G)
默认配置:2 * this.minFilesToCompact * this.region.memstoreFlushSize
hbase.hstore.compaction.max.size

  3)、建表时:

minor compact队列中storefile文件最大size
线上配置:21474836480(20G)
默认配置:Long.MAX_VALUE
hbase.rpc.timeout

                   a、如果不需要多版本,则应设置version=1;

RPC请求timeout时间
线上配置:300000(5min)
默认配置:60000(10s)
hbase.regionserver.region.split.policy

                   b、 开启lzo或者snappy压缩,压缩会消耗一定的CPU,但是,磁盘IO和网络IO将获得极大的改善,大致可以压缩4~5倍;

split操作默认的策略
线上配置: org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy(采取老的策略,自己控制split)
默认配置: org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy(在region没有达到maxFileSize的前提下,如果fileSize达到regionCount * regionCount * flushSize则进行split操作)
hbase.regionserver.regionSplitLimit

                  c、合理的设计rowkey,在设计rowkey时需充分的理解现有业务并合理预见未来业务,不合理的rowkey设计将导致极差的hbase操作性能;

单台RegionServer上region数上限
线上配置:150
默认配置:2147483647
hbase-env.sh配置
指定系统运行环境

                 d、合理的规划数据量,进行预分区,避免在表使用过程中的不断split,并把数据的读写分散到不同的RS,充分的发挥集群的作用;

export JAVA_HOME=/usr/lib/jvm/java-6-sun/ #JDK HOME
export HBASE_HOME=/home/hadoop/cdh4/hbase-0.94.2-cdh4.2.1 # HBase 安装目录
export HBASE_LOG_DIR=/mnt/dfs/11/hbase/hbase-logs #日志输出路径
JVM参数调优

                 e、列族名称尽量短,比如:“f”,并且尽量只有一个列族;

export HBASE_OPTS=”-verbose:gc -XX: PrintGCDetails -Xloggc:${HBASE_LOG_DIR}/hbase-gc.log -XX: PrintGCTimeStamps -XX: PrintGCApplicationConcurrentTime -XX: PrintGCApplicationStoppedTime
-server -Xmx20480m -Xms20480m -Xmn10240m -Xss256k -XX:SurvivorRatio=4 -XX:MaxPermSize=256m -XX:MaxTenuringThreshold=15
-XX:ParallelGCThreads=16 -XX: UseConcMarkSweepGC -XX: UseParNewGC -XX:CMSFullGCsBeforeCompaction=5 -XX: UseCMSCompactAtFullCollection
-XX: CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=70 -XX: UseCMSInitiatingOccupancyOnly -XX:CMSMaxAbortablePrecleanTime=5000

                 f、视场景开启bloomfilter,优化读性能。

/*

 

一次调用的时间轴大概是:(带*的为可缓存操作)
    1. getconnection在初始化时完成,不考虑。

    2. hConnection.getTable -> *zk取meta(hci.rpcTimeout) -> *meta ragion scan数据 ,超时与get类似,但callWithRetries里没有限制超时。

    3. hTable.get ->RpcRetryingCaller.callWithRetries(最小为callable.call超时 hbase.client.pause,最大为Max((callable.call超时 hbase.client.pause),(callable.call超时 hbase.client.pause hbase.client.operation.timeout)) ->

二、Client端调优

4、RpcClient.call中:

  1、hbase.client.write.buffer:写缓存大小,默认为2M,推荐设置为6M,单位是字节,当然不是越大越好,如果太大,则占用的内存太多;

socket建连超时:(ipc.socket.timeout hbase.client.pause)*hbase.ipc.client.connect.max.retries

 

socket超时:Min(hbase.rpc.timeout,Max(hbase.client.operation.timeout-已用时间,2000))
*/

  2、hbase.client.scanner.caching:scan缓存,默认为1,太小,可根据具体的业务特征进行配置,原则上不可太大,避免占用过多的client和rs的内存,一般最大几百,如果一条数据太大,则应该设置一个较小的值,通常是设置业务需求的一次查询的数据条数,比如:业务特点决定了一次最多100条,则可以设置为100

hbase client访问的超时时间、重试次数、重试间隔时间的配置
标签: hbase client 访问 | 发表时间:2014-05-17 15:28 | 作者:无尘道长
分享到: 出处:
超时时间、重试次数、重试时间间隔的配置也比较重要,因为默认的配置的值都较大,如果出现hbase集群或者RegionServer以及ZK关掉,则对应用程序是灾难性的,超时和重新等会迅速占满web容器的链接,导致web容器停止服务,关于socket的超时时间,有两种:1:建立连接的超时时间;2:读数据的超时时间。

 

可以配置如下几个参数:

  3、设置合理的超时时间和重试次数,具体的内容会在后续的blog中详细讲解。

  1. hbase.rpc.timeout:rpc的超时时间,默认60s,不建议修改,避免影响正常的业务,在线上环境刚开始配置的是3秒,运行半天后发现了大量的timeout error,原因是有一个region出现了如下问题阻塞了写操作:“Blocking updates … memstore size 434.3m is >= than blocking 256.0m size”可见不能太低。

  2. ipc.socket.timeout:socket建立链接的超时时间,应该小于或者等于rpc的超时时间,默认为20s

  3. hbase.client.retries.number:重试次数,默认为14,可配置为3

  4. hbase.client.pause:重试的休眠时间,默认为1s,可减少,比如100ms

  5. zookeeper.recovery.retry:zk的重试次数,可调整为3次,zk不轻易挂,且如果hbase集群出问题了,每次重试均会对zk进行重试操作,zk的重试总次数是:hbase.client.retries.number * zookeeper.recovery.retry,并且每次重试的休眠时间均会呈2的指数级增长,每次访问hbase均会重试,在一次hbase操作中如果涉及多次zk访问,则如果zk不可用,则会出现很多次的zk重试,非常浪费时间。

  6. zookeeper.recovery.retry.intervalmill:zk重试的休眠时间,默认为1s,可减少,比如:200ms

  7. hbase.regionserver.lease.period:scan查询时每次与server交互的超时时间,默认为60s,可不调整。

 

版本:0.94-cdh4.2.1

  4、client应用读写分离

    读和写分离,位于不同的tomcat实例,数据先写入redis队列,再异步写入hbase,如果写失败再回存redis队列,先读redis缓存的数据(如果有缓存,需要注意这里的redis缓存不是redis队列),如果没有读到再读hbase。

    当hbase集群不可用,或者某个RS不可用时,因为HBase的重试次数和超时时间均比较大(为保证正常的业务访问,不可能调整到比较小的值,如果一个RS挂了,一次读或者写,经过若干重试和超时可能会持续几十秒,或者几分钟),所以一次操作可能会持续很长时间,导致tomcat线程被一个请求长时间占用,tomcat的线程数有限,会被快速占完,导致没有空余线程做其它操作,读写分离后,写由于采用先写redis队列,再异步写hbase,因此不会出现tomcat线程被占满的问题, 应用还可以提供写服务,如果是充值等业务,则不会损失收入,并且读服务出现tomcat线程被占满的时间也会变长一些,如果运维介入及时,则读服务影响也比较有限。

 

  5、如果把org.apache.hadoop.hbase.client.HBaseAdmin配置为spring的bean,则需配置为懒加载,避免在启动时链接hbase的Master失败导致启动失败,从而无法进行一些降级操作。

 

  6、Scan查询编程优化:

     1)、调整caching;

     2)、如果是类似全表扫描这种查询,或者定期的任务,则可以设置scan的setCacheBlocks为false,避免无用缓存;

    3)、关闭scanner,避免浪费客户端和服务器的内存;

    4)、限定扫描范围:指定列簇或者指定要查询的列;

  5)、如果只查询rowkey时,则使用KeyOnlyFilter可大量减少网络消耗;

 

作为hbase依赖的状态协调者ZK和数据的存储则HDFS,也需要调优:

 

ZK调优:

  1、zookeeper.session.timeout:默认值3分钟,不可配置太短,避免session超时,hbase停止服务,线上生产环境由于配置为1分钟,出现过2次该原因导致的hbase停止服务,也不可配置太长,如果太长,当rs挂掉,zk不能快速知道,从而导致master不能及时对region进行迁移。

 

  2、zookeeper数量:至少5个节点。给每个zookeeper 1G左右的内存,最好有独立的磁盘。 (独立磁盘可以确保zookeeper不受影响).如果集群负载很重,不要把Zookeeper和RegionServer运行在同一台机器上面。就像DataNodes 和 TaskTrackers一样,只有超过半数的zk存在才会提供服务,比如:共5台,则最多只运行挂2台,配置4台与3台一样,最多只运行挂1台。

 

  3、hbase.zookeeper.property.maxClientCnxns:zk的最大连接数,默认为300,可配置上千

 

hdf调优:

  1、dfs.name.dir: namenode的数据存放地址,可以配置多个,位于不同的磁盘并配置一个NFS远程文件系统,这样nn的数据可以有多个备份

  2、dfs.data.dir:dn数据存放地址,每个磁盘配置一个路径,这样可以大大提高并行读写的能力

  3、dfs.namenode.handler.count:nn节点RPC的处理线程数,默认为10,需提高,比如:60

  4、dfs.datanode.handler.count:dn节点RPC的处理线程数,默认为3,需提高,比如:20

  5、dfs.datanode.max.xcievers:dn同时处理文件的上限,默认为256,需提高,比如:8192

  6、dfs.block.size:dn数据块的大小,默认为64M,如果存储的文件均是比较大的文件则可以考虑调大,比如,在使用hbase时,可以设置为128M,注意单位是字节

  7、dfs.balance.bandwidthPerSec:在通过start-balancer.sh做负载均衡时控制传输文件的速度,默认为1M/s,可配置为几十M/s,比如:20M/s

  8、dfs.datanode.du.reserved:每块磁盘保留的空余空间,应预留一些给非hdfs文件使用,默认值为0

  9、dfs.datanode.failed.volumes.tolerated:在启动时会导致dn挂掉的坏磁盘数量,默认为0,即有一个磁盘坏了,就挂掉dn,可以不调整。

 

 

 

 

引用:

编辑:编程 本文来源:1、hbase参数配置,写入请求会被拒绝

关键词: 澳门新濠3559