CDH优化

一、HDFS
dfs.block.size
HDFS中的数据block大小,默认是64M,对于较大集群,可以设置为128或264M

dfs.datanode.socket.write.timeout/dfs.socket.timeout
增加dfs.datanode.socket.write.timeout和dfs.socket.timeout两个属性的设置(默认300),比如30000,避免可能出现的IO超时异常

dfs.datanode.max.transfer.threads
增加datanode在进行文件传输时最大线程数(默认4096),比如8192,假设集群中有某台dataode主机的这个值比其他主机的大,那么这台主机上存储的数据相对别的主机比较多,导致数据分布不均匀的问题,即使balance仍然会不均匀

dfs.namenode.handler.count
设定 namenode server threads 的数量,默认是10,对于较大集群,可适当调大,比如64。这些 threads 會用 RPC 跟其他的 datanodes 沟通。当 datanodes 数量太多时会发現很容易出現 RPC timeout,解決方法是提升网络速度或提高这个值,但要注意的是 thread 数量多也表示 namenode 消耗的内存也随着增加

dfs.datanode.handler.count
datanode上用于处理RPC的线程数,默认是3,对于较大集群可适当调大,比如8。

二、YARN

yarn.app.mapreduce.am.resource.mb
ApplicationMaster的container占用的内存大小,可适当调低

mapreduce.map.memory.mb/mapreduce.reduce.memory.mb
作业的每个 Map/Reduce任务分配的物理内存量,参数大于最小容器内存(yarn.scheduler.minimum-allocation-mb),两个参数配置的值设置一样即可

mapreduce.map.java.opts.max.heap/mapreduce.reduce.java.opts.max.heap
每个Map/Reduce的JVM启动所占用的内存,正常此参数小于等于Map/Reduce申请的内存(mapreduce.map.memory.mb/mapreduce.reduce.memory.mb)的85%,因为map任务里不一定只跑java,比如hadoop streaming程序 io.file.buffer.size SequenceFiles 读取和写入操作的缓存区大小,还有map的输出都用到了这个缓冲区容量, 可减少 I/O 次数。建议设定为 64KB 到 128KB

mapreduce.task.io.sort.factor
Reduce Task中合并小文件时,一次合并的文件数据,每次合并的时候选择最小的前N个进行合并,此参数正常与mapreduce.task.io.sort.mb一起配置

mapreduce.task.io.sort.mb
Map Task缓冲区排序文件时要使用的内存缓冲总量,如果mapreduce.task.io.sort.factor设置了较大值,此参数也应相应调大 io.sort.spill.percent
mapreduce.task.io.sort.mb的阈值,默认是80%,当buffer中的数据达到这个阈值,后台线程会起来对buffer中已有的数据进行排序,然后写入磁盘

yarn.nodemanager.resource.memory-mb
NodeManager节点上可使用的物理内存总量,默认是8192(MB),根据节点所能分配的最大的内存进行分配即可(扣除其他服务内存、系统内存等)

yarn.scheduler.minimum-allocation-mb
容器可以请求的最小物理内存量,此参数小于等于作业分配的Map\Reduce内存量(mapreduce.map.memory.mb/mapreduce.reduce.memory.mb)

yarn.scheduler.increment-allocation-mb
内存规整化单位,为容器申请内存增量,最后内存请求数量将四舍五入为该数字最接近的倍数,比如使用 Fair Scheduler,Container请求资源是1.5GB,容量增量为1G,则将被调度器规整化为ceiling(1.5 GB / 1GB) * 1G ≈ 2GB(公式:(请求资源 / 容量增量)*容量增量 )

yarn.scheduler.maximum-allocation-mb
单个任务可申请的最大物理内存量(默认是8192(MB))。默认情况下,YARN采用了线程监控的方法判断任务是否超量使用内存,一旦发现超量,则直接将其杀死

三、HBASE
zookeeper.session.timeout
RegionServer与Zookeeper间的连接超时时间,默认180000ms(正常维持这个时间)。当超时时间到后,ReigonServer会被Zookeeper从集群清单中移除,HMaster收到移除通知后,会对这台server负责的regions重新balance,让其他存活的RegionServer接管,修改此参数也应该修改Zookeeper对应最大超时时间(maxSessionTimeout)

hbase.hregion.max.filesize
在当前ReigonServer上单个Reigon的最大存储空间,单个Region超过该值时,这个Region会被自动split成更小的region,一般512M以下的都算小region,根据实际情况可设置成5-10G大小

hbase.regionserver.handler.count
增大RegionServer中启动的 RPC服务器实例数量(默认10),比如50,此参数正常与hbase.client.write.buffer一起配置

hbase.client.write.buffer
增大htable客户端写缓冲区大小(默认是2097152),比如5M,缓冲区是为了写数据的临时存放,设置大了,浪费客户端和服务端的存储,设置小了,如果写的数据多,太多的RPC又带来网络开销,官方给的一个服务端存储耗费评估计算是:hbase.client.write.buffer*hbase.regionserver.handler.count,服务端的region server的处理handler个数也很关键

hbase.hregion.memstore.flush.size
当单个memstore达到指定值时,flush该memstore(一台ReigonServer可能有成百上千个memstore),CDH5.2.0默认大小为128M,内存允许情况下,适当调高此参数,可避免过多的flush

hbase.regionserver.global.memstore.upperLimit/lowerLimit
这是一个Heap内存保护参数,默认值已经能适用大多数场景(如非特殊情况,不做修改)。

hbase.regionserver.global.memstore.upperLimit的意思是当ReigonServer内所有的memstore所占用的内存总和达到heap的hbase.regionserver.global.memstore.upperLimit大小时,HBase会强制block所有的更新并flush这些memstore以释放所有memstore占用的内存;

hbase.regionserver.global.memstore.lowserLimit的意思是当全局memstore的内存达到hbase.regionserver.global.memstore.lowserLimit大小时,它不会flush所有的memstore,它会找一些内存占用较大的 memstore,做个别flush,当然更新还是会被block

hfile.block.cache.size
该值直接影响数据读的性能,storefile的读缓存占用Heap的大小百分比。如果读比写少,0.4-0.5,如果读写较均衡,0.3左右。如果写比读多,默认即可。设置这个值的时候,需要参考

hbase.regionserver.global.memstore.upperLimit,如果两值加起来超过80-90%,会有OOM的风险

hbase.hstore.blockingStoreFiles
在compaction时,如果一个Store(Coulmn Family)内有超过base.hstore.blockingStoreFiles个storefile需要合并,则block所有的写请求,进行flush,限制storefile数量增长过快,直到完成压缩或直到超过为 hbase.hstore.blockingWaitTime指定的值。但是block写请求会影响当前region的性能,将值设为单个region可以支撑的最大store file数量会是个不错的选择,即允许comapction时,memstore继续生成storefile。最大storefile数量可通过 hbase.hregion.max.filesize/hbase.hregion.memstore.flush.size来计算 hbase.hstore.blockingWaitTime
达到由hbase.hstore.blockingStoreFiles指定的 HStoreFile 限制后,HRegion 阻止更新的时间段。此时间段过后,HRegion 将停止阻止更新,即使尚未完成压缩,即写请求继续被处理,可适当增大是参数
hbase.client.scanner.caching
scanner一次缓存多少数据来scan(从服务端一次读取多少数据回来scan),内存允许情况下,增大此参数

SOLR
Solr Server 的 Java 堆栈大小
Java 进程堆栈内存的最大大小,传递到Java -Xmx,内存允许情况下,调高此参数 Solr 服务器的 Java 直接内存大小 由Java进程分配的最大堆栈外内存量。传递到 Java -XX:MaxDirectMemorySize。如果未设置,则默认为堆的大小,内存允许情况下,调高此参数 schema.xml优化

  1. 将所有只用于搜索的,而不需要作为结果的field(特别是一些比较大的field)的stored设置为false
  2. 将不需要被用于搜索的,而只是作为结果返回的field的indexed设置为false
  3. 删除所有不必要的copyField声明
  4. 使用尽可能高的Log输出等级,减少日志量 solrConfig.xml优化
  5. 增大maxBufferedDocs大小,增加服务器接收批量请求数,也可通过增加ramBuffe
    rSizeMB大小来增加服务器buffer
    ZOOKEEPER
    maxClientCnxns
    增大此参数,增加最大客户端连接数 maxSessionTimeout
    增大此参数,增加最大会话时间
  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
CDH大数据运维,也就是Cloudera的分布式数据平台运维。CDH是Cloudera公司基于Apache Hadoop开发的商业版分布式数据平台,主要用于存储和处理大规模数据。CDH大数据运维通常包括以下几个方面: 1. 集群部署和配置:CDH运维首先要进行集群的部署和配置,包括选择合适的硬件、安装操作系统、配置网络环境等。此外,还需要对CDH的各个组件进行适当的配置,如Hadoop、HBase、Impala等,以满足各种数据处理需求。 2. 资源管理和调度:CDH运维需要对集群中的资源进行管理和调度,以确保任务的顺利执行。这包括对CPU、内存、磁盘等资源的监控和分配,以及对任务的调度和优化。 3. 数据备份和恢复:CDH大数据运维还需要对存储在集群中的数据进行备份和恢复。这可以通过设置合适的数据备份策略和使用分布式文件系统来实现。当数据丢失或损坏时,可以快速恢复数据,确保数据的完整性和可靠性。 4. 性能优化CDH大数据运维需要进行性能优化,以提高数据处理的效率和响应速度。这包括对集群中的各个组件进行调优和配置优化,以减少资源消耗和提高数据处理能力。 总之,CDH大数据运维是一个综合性的工作,需要对分布式数据平台进行部署、配置、资源管理、备份恢复和性能优化等方面的工作。它的目标是确保集群的稳定运行,保障数据的安全性和可用性,提高数据处理的效率和性能。CDH大数据运维对于企业来说非常重要,可以帮助他们更好地利用大数据进行业务决策和创新。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值