欧美一级特黄大片做受成人-亚洲成人一区二区电影-激情熟女一区二区三区-日韩专区欧美专区国产专区

三、hbase--調(diào)優(yōu)-創(chuàng)新互聯(lián)

這里主要講hbase調(diào)優(yōu)相關(guān)內(nèi)容

在灤平等地區(qū),都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局,加強(qiáng)發(fā)展的系統(tǒng)性、市場(chǎng)前瞻性、產(chǎn)品創(chuàng)新能力,以專(zhuān)注、極致的服務(wù)理念,為客戶提供網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站建設(shè) 網(wǎng)站設(shè)計(jì)制作按需網(wǎng)站設(shè)計(jì),公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站制作,全網(wǎng)整合營(yíng)銷(xiāo)推廣,外貿(mào)營(yíng)銷(xiāo)網(wǎng)站建設(shè),灤平網(wǎng)站建設(shè)費(fèi)用合理。

一、Hmaster高可用

在HBase中Hmaster負(fù)責(zé)監(jiān)控RegionServer的生命周期,均衡RegionServer的負(fù)載,如果Hmaster掛掉了,那么整個(gè)HBase集群將陷入不健康的狀態(tài),并且此時(shí)的工作狀態(tài)并不會(huì)維持太久。所以HBase支持對(duì)Hmaster的高可用配置。
首先在 $HBASE_HOME/conf 下創(chuàng)建一個(gè) backup-masters 名稱的文件,注意,一定得是這個(gè)名字。文件內(nèi)容是備Hmaster的主機(jī)名或者ip

vim backup-masters
bigdata122

接著把這個(gè)文件復(fù)制其他hbase節(jié)點(diǎn)的hbase的conf目錄下

scp backup-masters bigdata122:/opt/modules/hbase-1.3.1/conf/
scp backup-masters bigdata123:/opt/modules/hbase-1.3.1/conf/

接著重啟整個(gè)hbase集群

stop-hbase.sh
start-hbase.sh

接著通過(guò) http://bigdata121:16010 可以看到備節(jié)點(diǎn)的情況
這會(huì)在zk的 hbase/backup-masters/節(jié)點(diǎn)下面以節(jié)點(diǎn)信息為名,創(chuàng)建一個(gè)節(jié)點(diǎn),例如:

[zk: localhost:2181(CONNECTED) 6] ls /hbase/backup-masters 
[bigdata122,16000,1564564196379]

二、hadoop通用性優(yōu)化

2.1 namenode元數(shù)據(jù)存儲(chǔ)使用SSD
2.2 定時(shí)備份namenode上的元數(shù)據(jù)(如果配置了高可用就不需要了)

2.3 為namenode數(shù)據(jù)目錄指定多個(gè)元數(shù)據(jù)目錄
使用dfs.name.dir或者dfs.namenode.name.dir指定多個(gè)同樣的元數(shù)據(jù)目錄。這樣可以提供元數(shù)據(jù)的冗余和健壯性,以免發(fā)生故障。具體配置可以看“namenode工作機(jī)制”這篇文章

2.4 NameNode的dir自恢復(fù)
設(shè)置dfs.namenode.name.dir.restore為true,允許嘗試恢復(fù)之前失敗的dfs.namenode.name.dir目錄,在創(chuàng)建checkpoint時(shí)做此嘗試,如果設(shè)置了多個(gè)磁盤(pán),建議允許。

2.5 HDFS保證RPC調(diào)用會(huì)有較多的線程數(shù)
hdfs是使用rpc進(jìn)行訪問(wèn)通信的,所以rpc調(diào)用的線程數(shù)決定了并發(fā)性能

hdfs-site.xml
屬性:dfs.namenode.handler.count
解釋?zhuān)涸搶傩允荖ameNode服務(wù)默認(rèn)線程數(shù),的默認(rèn)值是10,根據(jù)機(jī)器的可用內(nèi)存可以調(diào)整為50~100

屬性:dfs.datanode.handler.count
解釋?zhuān)涸搶傩阅J(rèn)值為10,是DataNode的處理線程數(shù),如果HDFS客戶端程序讀寫(xiě)請(qǐng)求比較多,可以調(diào)高到15~20,設(shè)置的值越大,內(nèi)存消耗越多,不要調(diào)整的過(guò)高,一般業(yè)務(wù)中,5~10即可。

2.6 hdfs副本數(shù)

hdfs-site.xml
屬性:dfs.replication
解釋?zhuān)喝绻麛?shù)據(jù)量巨大,且不是非常之重要,可以調(diào)整為2~3,如果數(shù)據(jù)非常之重要,可以調(diào)整為3~5。

2.7 hdfs文件塊大小調(diào)整

hdfs-site.xml
屬性:dfs.blocksize
解釋?zhuān)簤K大小定義,該屬性應(yīng)該根據(jù)存儲(chǔ)的大量的單個(gè)文件大小來(lái)設(shè)置,如果大量的單個(gè)文件都小于100M,建議設(shè)置成64M塊大小,對(duì)于大于100M或者達(dá)到GB的這種情況,建議設(shè)置成256M,一般設(shè)置范圍波動(dòng)在64M~256M之間。

2.8 MapReduce Job任務(wù)服務(wù)線程數(shù)調(diào)整

mapred-site.xml
屬性:mapreduce.jobtracker.handler.count
解釋?zhuān)涸搶傩允荍ob任務(wù)線程數(shù),默認(rèn)值是10,根據(jù)機(jī)器的可用內(nèi)存可以調(diào)整為50~100

2.9 http服務(wù)器工作線程數(shù)

mapred-site.xml
屬性:mapreduce.tasktracker.http.threads
解釋?zhuān)憾xHTTP服務(wù)器工作線程數(shù),默認(rèn)值為40,對(duì)于大集群可以調(diào)整到80~100

2.10 文件排序合并優(yōu)化

mapred-site.xml
屬性:mapreduce.task.io.sort.factor
解釋?zhuān)何募判驎r(shí)同時(shí)合并的數(shù)據(jù)流的數(shù)量,這也定義了同時(shí)打開(kāi)文件的個(gè)數(shù),默認(rèn)值為10,如果調(diào)高該參數(shù),可以明顯減少磁盤(pán)IO,即減少文件讀取的次數(shù)。在merge過(guò)程中,同時(shí)打開(kāi)的文件數(shù)量越多,可以減少對(duì)磁盤(pán)的多次調(diào)用。

2.11 設(shè)置任務(wù)并發(fā)

mapred-site.xml
屬性:mapreduce.map.speculative
解釋?zhuān)涸搶傩钥梢栽O(shè)置任務(wù)是否可以并發(fā)執(zhí)行,如果任務(wù)多而小,該屬性設(shè)置為true可以明顯加快任務(wù)執(zhí)行效率,但是對(duì)于延遲非常高的任務(wù),建議改為false,這就類(lèi)似于迅雷下載。

2.12 MR輸出數(shù)據(jù)的壓縮

mapred-site.xml
屬性:mapreduce.map.output.compress、    這是map輸出mapreduce.output.fileoutputformat.compress   這是reduce輸出
解釋?zhuān)簩?duì)于大集群而言,建議設(shè)置Map-Reduce的輸出為壓縮的數(shù)據(jù),而對(duì)于小集群,則不需要。

2.13 優(yōu)化Mapper和Reducer的個(gè)數(shù)

mapred-site.xml
屬性:
mapreduce.tasktracker.map.tasks.maximum
mapreduce.tasktracker.reduce.tasks.maximum
解釋?zhuān)阂陨蟽蓚€(gè)屬性分別為一個(gè)單獨(dú)的Job任務(wù)可以同時(shí)運(yùn)行的Map和Reduce的數(shù)量。
設(shè)置上面兩個(gè)參數(shù)時(shí),需要考慮CPU核數(shù)、磁盤(pán)和內(nèi)存容量。假設(shè)一個(gè)8核的CPU,業(yè)務(wù)內(nèi)容非常消耗CPU,那么可以設(shè)置map數(shù)量為4,如果該業(yè)務(wù)不是特別消耗CPU類(lèi)型的,那么可以設(shè)置map數(shù)量為40,reduce數(shù)量為20。這些參數(shù)的值修改完成之后,一定要觀察是否有較長(zhǎng)等待的任務(wù),如果有的話,可以減少數(shù)量以加快任務(wù)執(zhí)行,如果設(shè)置一個(gè)很大的值,會(huì)引起大量的上下文切換,以及內(nèi)存與磁盤(pán)之間的數(shù)據(jù)交換,這里沒(méi)有標(biāo)準(zhǔn)的配置數(shù)值,需要根據(jù)業(yè)務(wù)和硬件配置以及經(jīng)驗(yàn)來(lái)做出選擇。
在同一時(shí)刻,不要同時(shí)運(yùn)行太多的MapReduce,這樣會(huì)消耗過(guò)多的內(nèi)存,任務(wù)會(huì)執(zhí)行的非常緩慢,我們需要根據(jù)CPU核數(shù),內(nèi)存容量設(shè)置一個(gè)MR任務(wù)并發(fā)的大值,使固定數(shù)據(jù)量的任務(wù)完全加載到內(nèi)存中,避免頻繁的內(nèi)存和磁盤(pán)數(shù)據(jù)交換,從而降低磁盤(pán)IO,提高性能。

大概估算公式:
map = 2 + ?cpu_core
reduce = 2 + ?cpu_core

三、Linux優(yōu)化

3.1開(kāi)啟文件系統(tǒng)的預(yù)讀緩存可以提高讀取速度

sudo blockdev --setra 32768 /dev/sda

ra是readahead的縮寫(xiě)

3.2 關(guān)閉進(jìn)程睡眠池
即不允許后臺(tái)進(jìn)程進(jìn)入睡眠狀態(tài),如果進(jìn)程空閑,則直接kill掉釋放資源

sudo sysctl -w vm.swappiness=0

3.3 禁用Linux文件的atime
文件每次訪問(wèn)會(huì)更新atime(access time),而hdfs底層是一個(gè)block存儲(chǔ)為一個(gè)文件,所以文件的數(shù)量是很多的,如果每次訪問(wèn)一次都刷新一次atime,其實(shí)沒(méi)什么必要,可以將存儲(chǔ)hdfs文件的設(shè)備的atime關(guān)閉掉。

vim /etc/fstab
UUID=6086522b-3bc7-44a2-83f4-fd79a8c4afa1 / ext4 errors=remount-ro,noatime,nodiratime 0 1

在工作參數(shù)中,添加noatime就是表示禁用atime

3.4 調(diào)整ulimit上限,默認(rèn)值為比較小的數(shù)字

ulimit -n 查看允許大進(jìn)程數(shù)
ulimit -u 查看允許打開(kāi)大文件數(shù)

vi /etc/security/limits.conf 修改打開(kāi)文件數(shù)限制
末尾添加:
*                soft    nofile          1024000
*                hard    nofile          1024000
Hive             -       nofile          1024000
Hive             -       nproc           1024000 

vi /etc/security/limits.d/20-nproc.conf 修改用戶打開(kāi)進(jìn)程數(shù)限制
修改為:
#*          soft    nproc     4096
#root       soft    nproc     unlimited
*          soft    nproc     40960
root       soft    nproc     unlimited

3.5 開(kāi)啟集群時(shí)間同步
集群時(shí)間如果不同步,在節(jié)點(diǎn)心跳檢查的時(shí)候,可能會(huì)有問(wèn)題。

四、zookeeper優(yōu)化

優(yōu)化Zookeeper會(huì)話超時(shí)時(shí)間

hbase-site.xml
參數(shù):zookeeper.session.timeout
解釋?zhuān)篒n hbase-site.xml, set zookeeper.session.timeout to 30 seconds or less to bound failure detection (20-30 seconds is a good start).該值會(huì)直接關(guān)系到master發(fā)現(xiàn)服務(wù)器宕機(jī)的大周期,默認(rèn)值為30秒(不同的HBase版本,該默認(rèn)值不一樣),如果該值過(guò)小,會(huì)在HBase在寫(xiě)入大量數(shù)據(jù)發(fā)生而GC時(shí),導(dǎo)致RegionServer短暫的不可用,從而沒(méi)有向ZK發(fā)送心跳包,最終導(dǎo)致認(rèn)為從節(jié)點(diǎn)shutdown。一般20臺(tái)左右的集群需要配置5臺(tái)zookeeper。

五、hbase優(yōu)化

5.1 預(yù)分區(qū)

? 每一個(gè)region維護(hù)著startRowKey與endRowKey,如果加入的數(shù)據(jù)符合某個(gè)region維護(hù)的rowKey范圍,則該數(shù)據(jù)交給這個(gè)region維護(hù)。那么依照這個(gè)原則,我們可以將數(shù)據(jù)索要投放的分區(qū)提前大致的規(guī)劃好,以提高HBase性能。盡量將讀寫(xiě)請(qǐng)求均衡地分發(fā)到不同分區(qū)的region中,這才是我們想要的。

數(shù)據(jù)傾斜查看:
在hbase的web頁(yè)面中,可以點(diǎn)擊每個(gè)table,然后進(jìn)去查看表的在不同region的狀態(tài),其中有一列“request”,表示該表的不同的region接收到的請(qǐng)求個(gè)數(shù)。由此可以判斷出不同region間是否存在數(shù)據(jù)傾斜。

分區(qū)方式:
(1)手動(dòng)設(shè)定預(yù)分區(qū)

hbase> create 'staff','info','partition1',SPLITS => ['1000','2000','3000','4000']

這會(huì)分為5個(gè)區(qū):
小于1000
1000~2000
2000~3000
3000~4000
大于4000

可以在hbase的web頁(yè)面的table detials中點(diǎn)擊對(duì)應(yīng)的表,進(jìn)去查看到每個(gè)表的分區(qū)情況。
也可以通過(guò)以下命令查看分區(qū):

hbase(main):011:0> get_splits 'staff'
Total number of splits = 5

=> ["1000", "2000", "3000", "4000"]

(2)生成16進(jìn)制序列預(yù)分區(qū)

create 'staff2','info','partition2',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

(3)根據(jù)文件設(shè)置的規(guī)則預(yù)分區(qū)
創(chuàng)建文件如下:
split.txt

aaaa
bbbb
cccc
dddd

創(chuàng)建表:

create 'staff3','partition3',SPLITS_FILE => 'splits.txt'

分區(qū)創(chuàng)建如下:
....~aaaa
aaaa~bbbb
bbbb~cccc
cccc~dddd
dddd~....

5.2 rowkey設(shè)計(jì)

一條數(shù)據(jù)的唯一標(biāo)識(shí)就是rowkey,那么這條數(shù)據(jù)存儲(chǔ)于哪個(gè)分區(qū),取決于rowkey處于哪個(gè)一個(gè)預(yù)分區(qū)的區(qū)間內(nèi),設(shè)計(jì)rowkey的主要目的 ,就是讓數(shù)據(jù)均勻的分布于所有的region中,在一定程度上防止數(shù)據(jù)傾斜。接下來(lái)我們就談一談rowkey常用的設(shè)計(jì)方案。而且rowkey的設(shè)計(jì)越隨機(jī)越好,越?jīng)]有規(guī)律越好,這樣才能更加隨機(jī)的分布到不同region中,從而均衡讀寫(xiě)壓力

5.2.1 生成隨機(jī)數(shù)、hash、散列值

比如:
原本rowKey為1001的,SHA1后變成:dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本rowKey為3001的,SHA1后變成:49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本rowKey為5001的,SHA1后變成:7b61dec07e02c188790670af43e717f0f46e8913
在做此操作之前,一般我們會(huì)選擇從數(shù)據(jù)集中抽取樣本,來(lái)決定什么樣的rowKey來(lái)Hash后作為每個(gè)分區(qū)的臨界值。

5.2.2 字符串反轉(zhuǎn)

常用一些有規(guī)律的數(shù)據(jù),將其變?yōu)檩^弱規(guī)律的數(shù)據(jù),常見(jiàn)的比如電話號(hào)碼、identification card號(hào)碼、日期時(shí)間等。這些數(shù)據(jù)都是有規(guī)律,而將他們反轉(zhuǎn)后,就相對(duì)隨機(jī)一些了。

這樣也可以在一定程度上散列逐步put進(jìn)來(lái)的數(shù)據(jù)。

5.2.3 字符串拼接

rowkey本身有規(guī)律,也可以在前面或者后面添加一些隨機(jī)字符,將rowkey規(guī)律打亂,變成較為隨機(jī)的數(shù)據(jù)

5.3 內(nèi)存優(yōu)化

因?yàn)閔base 作為一款內(nèi)存型的nosql,對(duì)內(nèi)存的使用量是很大的,那么如果規(guī)劃內(nèi)存與hbase的性能密切相關(guān)。內(nèi)存優(yōu)化這方面主要集中在3個(gè)方面:compact、flush以及內(nèi)存區(qū)域規(guī)劃

5.3.1 compact

compact操作就是將多個(gè)storefile合并,主要是為了壓縮存儲(chǔ)空間,提高讀寫(xiě)速度。根據(jù)合并的規(guī)模,分為 Minor Compaction 和 Major Compaction
Minor Compaction:

是指選取一些小的、相鄰的StoreFile將他們合并成一個(gè)更大的StoreFile,在這個(gè)過(guò)程中不會(huì)處理已經(jīng)Deleted或Expired的Cell。一次Minor Compaction的結(jié)果是更少并且更大的StoreFile。

Major Compaction

是指將所有的StoreFile合并成一個(gè)StoreFile,這個(gè)過(guò)程還會(huì)清理三類(lèi)無(wú)意義數(shù)據(jù):被刪除的數(shù)據(jù)、TTL過(guò)期數(shù)據(jù)、版本號(hào)超過(guò)設(shè)定版本號(hào)的數(shù)據(jù)。另外,一般情況下,Major Compaction時(shí)間會(huì)持續(xù)比較長(zhǎng),整個(gè)過(guò)程會(huì)消耗大量系統(tǒng)資源,對(duì)上層業(yè)務(wù)有比較大的影響。因此線上業(yè)務(wù)都會(huì)將關(guān)閉自動(dòng)觸發(fā)Major Compaction功能,改為手動(dòng)在業(yè)務(wù)低峰期觸發(fā)

minor compaction通常會(huì)由memstore flush,線程定期檢查觸發(fā)。major compaction通常會(huì)由手動(dòng)觸發(fā),可以通過(guò)參數(shù),hbase.hregion.majorcompaction設(shè)置為0即可,默認(rèn)時(shí)間為一天86400000。

手動(dòng)compact操作:
Minor Compaction

compact 'namespace:table','cf'
如果不指定cf,就會(huì)合并整個(gè)region

Major Compaction

major_compact 'namespace:table','cf'   用法和上面類(lèi)似

5.3.2 flush

flush就是從memstore將數(shù)據(jù)刷寫(xiě)到storefile中,hbase寫(xiě)數(shù)據(jù),先寫(xiě)wal的hlog,成功后才寫(xiě)memstore,每個(gè)列只有多有一個(gè)memstore,當(dāng)一個(gè)region所有cf的memstore大小之和達(dá)到hbase.regionserver.global.memstore.size設(shè)置的大小時(shí),這個(gè)值默認(rèn)是128M,就會(huì)flush。當(dāng)前單個(gè)cf 的memstore達(dá)到這個(gè)值也會(huì)flush的,這種非實(shí)時(shí)的flush操作主要是為了較好的寫(xiě)性能,避免每次寫(xiě)都要flush到hdfs中。在hbase2.0版本中,memstore其實(shí)是由一個(gè)可變的memstore和許多不可變的memstore組成,直接在內(nèi)存中進(jìn)行compaction,如果flush成HFile,再compaction,會(huì)占用大量磁盤(pán)和網(wǎng)絡(luò)IO。

5.3.3 內(nèi)存規(guī)劃

如何分配合適的內(nèi)存給regionserver,以及regionserver內(nèi)部不同功能性內(nèi)存的大小需要是很考究的。可以大致分為以下幾個(gè)區(qū)域的內(nèi)存:

CombinedBlockCache:
負(fù)責(zé)讀緩存,分為 LRUBlockCache和BucketCache。前者一般用來(lái)緩存數(shù)據(jù)的元數(shù)據(jù),而且屬于堆內(nèi)內(nèi)存,后者用來(lái)緩存原始數(shù)據(jù),屬于堆外內(nèi)存.

memstore:
負(fù)責(zé)寫(xiě)緩存,用來(lái)存儲(chǔ)可以直接修改的數(shù)據(jù)的

other:
用于存儲(chǔ)hbase工作過(guò)程中的對(duì)象

jvm_heap:
就是減去BucketCache后的大小。一般就是 memstore+LRUBlockCache+other

有一個(gè)硬性要求:LRUBlockCache + MemStore < 80% * JVM_HEAP
不滿足這個(gè)條件,rs直接無(wú)法啟動(dòng)

分為兩種場(chǎng)景:讀少寫(xiě)多,讀多寫(xiě)少。
1、讀少寫(xiě)多

一般用 LRUBlockCache 模式,也就是 LRUBlockCache + memstore + other的模式。
都在堆內(nèi)內(nèi)存中。

以機(jī)器內(nèi)存為96G為例,一般分配給rs的 2/3的內(nèi)存,也就是64G。
首先memstore要比LRUBlockCache大,且LRUBlockCache + MemStore < 80% * JVM_HEAP
推薦以下規(guī)劃:
MemStore = 45% * JVM_HEAP = 64G * 45% = 28.8G ,LRUBlockCache = 30% * JVM_HEAP = 64G * 30% = 19.2G;默認(rèn)情況下Memstore為40% * JVM_HEAP,而LRUBlockCache為25% * JVM_HEAP

jvm參數(shù)配置:

-XX:SurvivorRatio=2  -XX:+PrintGCDateStamps  -Xloggc:$HBASE_LOG_DIR/gc-regionserver.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=512M -server -Xmx64g -Xms64g -Xmn2g -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:MaxTenuringThreshold=15  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

其中 -Xmx64g -Xms64g 設(shè)置堆內(nèi)存為 64g

hbase-stie.xml中的配置

<!--memstore的配置-->
由上述定義可知,hbase.regionserver.global.memstore.upperLimit設(shè)置為0.45,hbase.regionserver.global.memstore.lowerLimit設(shè)置為0.40
hbase.regionserver.global.memstore.upperLimit表示RegionServer中所有MemStore占有內(nèi)存在JVM內(nèi)存中的比例上限。如果所占比例超過(guò)這個(gè)值,RS會(huì)首先將所有Region按照MemStore大小排序,并按照由大到小的順序依次執(zhí)行flush,直至所有MemStore內(nèi)存總大小小于hbase.regionserver.global.memstore.lowerLimit,一般lowerLimit比upperLimit小5%。
<property>
    <name>hbase.regionserver.global.memstore.upperLimit</name>
    <value>0.45</value>
</property>
<property>
    <name>hbase.regionserver.global.memstore.lowerLimit</name>
    <value>0.40</value>
</property>

<!--LRUBlockCache的配置-->
<property>
    <name>hfile.block.cache.size</name>
    <value>0.3</value>
</property>

2、讀多寫(xiě)少

一般用BucketCache,也就是讀內(nèi)存包括 BucketCache和 LRUBlockCache。兩者共同構(gòu)成CombinedBlockCache
采用以下內(nèi)存分布:
堆內(nèi)內(nèi)存:LRUBlockCache + memstore + other
堆外內(nèi)存:BucketCache

以機(jī)器內(nèi)存為96G為例,一般分配給rs的 2/3的內(nèi)存,也就是64G。也可以更多的
這種情況,讀、寫(xiě)、其他內(nèi)存的比例一般為 5:3:2,讀內(nèi)存中 LRU:BUCKET= 1:9
同時(shí)要滿足 LRUBlockCache + MemStore < 80% * JVM_HEAP
CombinedBlockCache 64* 0.5=32
-----LRUBlockCache  32*0.1
-----BucketCache    32*0.9
memstore           64*0.3
heap               64 - 32*0.9
計(jì)算之后,LRU + MemStore / JVM_HEAP = 3.2G + 19.2G / 35.2G = 22.4G / 35.2G =  63.6% ,遠(yuǎn)小于80%。因此需要調(diào)整一下對(duì)應(yīng)的大小。這種情況證明堆內(nèi)存太大了,適量減少JVM_HEAP值(減少至30G),增大Memstore到20G。因?yàn)镴VM_HEAP減少了,堆外內(nèi)存就需要適量增大,因此將BucketCache增大到30G。
調(diào)整之后,LRU + MemStore / JVM_HEAP = 3.2G + 20G / 30G = 23.2G / 30G =  77%

jvm參數(shù)設(shè)置

-XX:SurvivorRatio=2  -XX:+PrintGCDateStamps  -Xloggc:$HBASE_LOG_DIR/gc-regionserver.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=1 -XX:GCLogFileSize=512M -server -Xmx40g -Xms40g -Xmn1g -Xss256k -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+UseParNewGC -XX:MaxTenuringThreshold=15  -XX:+CMSParallelRemarkEnabled -XX:+UseCMSCompactAtFullCollection -XX:+CMSClassUnloadingEnabled -XX:+UseCMSInitiatingOccupancyOnly -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

hbase-site.xml配置

memstore相關(guān):
根據(jù)upperLimit參數(shù)的定義,結(jié)合上述內(nèi)存規(guī)劃數(shù)據(jù)可計(jì)算出 upperLimit =  20G / 30G = 66%。因此upperLimit參數(shù)設(shè)置為0.66,lowerLimit設(shè)置為0.60
<property>
    <name>hbase.regionserver.global.memstore.upperLimit</name>
    <value>0.66</value>
</property>
<property>
    <name>hbase.regionserver.global.memstore.lowerLimit</name>
    <value>0.60</value>
</property>

CombinedBlockCache相關(guān):
<property> 設(shè)置為堆外內(nèi)存
    <name>hbase.bucketcache.ioengine</name>
    <value>offheap</value>
</property>
<property> 堆外內(nèi)存大小
    <name>hbase.bucketcache.size</name>
    <value>34816</value>
</property>
<property> bucketcache的比例
    <name>hbase.bucketcache.percentage.in.combinedcache</name>
    <value>0.90</value>
</property>

更加詳細(xì)的請(qǐng)看:http://hbasefly.com/2016/06/18/hbase-practise-ram/ 寫(xiě)的超好。

5.4 基礎(chǔ)優(yōu)化

1、允許hdfs文件中追加內(nèi)容

hdfs-site.xml、hbase-site.xml
屬性:dfs.support.append
解釋?zhuān)洪_(kāi)啟HDFS追加同步,可以優(yōu)秀的配合HBase的數(shù)據(jù)同步和持久化。默認(rèn)值為true。

2、優(yōu)化DataNode允許的大文件打開(kāi)數(shù)

hdfs-site.xml
屬性:dfs.datanode.max.transfer.threads
解釋?zhuān)篐Base一般都會(huì)同一時(shí)間操作大量的文件,根據(jù)集群的數(shù)量和規(guī)模以及數(shù)據(jù)動(dòng)作,設(shè)置為4096或者更高。默認(rèn)值:4096

3、優(yōu)化延遲高的數(shù)據(jù)操作的等待時(shí)間

hdfs-site.xml
屬性:dfs.image.transfer.timeout
解釋?zhuān)喝绻麑?duì)于某一次數(shù)據(jù)操作來(lái)講,延遲非常高,socket需要等待更長(zhǎng)的時(shí)間,建議把該值設(shè)置為更大的值(默認(rèn)60000毫秒),以確保socket不會(huì)被timeout掉

4、優(yōu)化DataNode存儲(chǔ)

屬性:dfs.datanode.failed.volumes.tolerated
解釋?zhuān)?默認(rèn)為0,意思是當(dāng)DataNode中有一個(gè)磁盤(pán)出現(xiàn)故障,則會(huì)認(rèn)為該DataNode shutdown了。如果修改為1,則一個(gè)磁盤(pán)出現(xiàn)故障時(shí),數(shù)據(jù)會(huì)被復(fù)制到其他正常的DataNode上,當(dāng)前的DataNode繼續(xù)工作。

5、設(shè)置regionserver的RPC監(jiān)聽(tīng)數(shù)量

hbase-site.xml
屬性:hbase.regionserver.handler.count
解釋?zhuān)耗J(rèn)值為30,用于指定RPC監(jiān)聽(tīng)的數(shù)量,可以根據(jù)客戶端的請(qǐng)求數(shù)進(jìn)行調(diào)整,讀寫(xiě)請(qǐng)求較多時(shí),增加此值。

6、優(yōu)化HStore文件大小

屬性:hbase.hregion.max.filesize
解釋?zhuān)耗J(rèn)值10737418240(10GB),如果需要運(yùn)行HBase的MR任務(wù),可以減小此值,因?yàn)橐粋€(gè)region對(duì)應(yīng)一個(gè)map任務(wù),如果單個(gè)region過(guò)大,會(huì)導(dǎo)致map任務(wù)執(zhí)行時(shí)間過(guò)長(zhǎng)。該值的意思就是,如果HFile的大小達(dá)到這個(gè)數(shù)值,則這個(gè)region會(huì)被切分為兩個(gè)。

7、優(yōu)化hbase客戶端緩存

hbase-site.xml
屬性:hbase.client.write.buffer
解釋?zhuān)河糜谥付℉Base客戶端緩存,增大該值可以減少RPC調(diào)用次數(shù),但是會(huì)消耗更多內(nèi)存,反之則反之。一般我們需要設(shè)定一定的緩存大小,以達(dá)到減少RPC次數(shù)的目的。

8、指定scan.next掃描HBase所獲取的行數(shù)

hbase-site.xml
屬性:hbase.client.scanner.caching
解釋?zhuān)河糜谥付╯can.next方法獲取的默認(rèn)行數(shù),值越大,消耗內(nèi)存越大。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)cdcxhl.cn,海內(nèi)外云服務(wù)器15元起步,三天無(wú)理由+7*72小時(shí)售后在線,公司持有idc許可證,提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案,具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì),專(zhuān)為企業(yè)上云打造定制,能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

網(wǎng)站標(biāo)題:三、hbase--調(diào)優(yōu)-創(chuàng)新互聯(lián)
文章URL:http://aaarwkj.com/article6/jcsog.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站內(nèi)鏈、搜索引擎優(yōu)化、建站公司外貿(mào)建站、域名注冊(cè)App開(kāi)發(fā)

廣告

聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請(qǐng)盡快告知,我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如需處理請(qǐng)聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來(lái)源: 創(chuàng)新互聯(lián)

成都網(wǎng)站建設(shè)
日本午夜福利久久久| 日本免费熟女一区二区| 美女露脸口爆吞精视频| 亚洲特级黄色做啪啪啪| 日韩精品一区二区av在线| 美女一区二区三区日本美女在线观看 | 男人天堂av在线资源| 久久精品国产亚洲av一| 成人18禁h黄在线看免费| 青草视频在线播放免费| 国产精品自拍av一区二区| 中文字幕亚洲无级av| 日本在线视频精品一区| 亚洲欧美日韩制服另类| 91国内精品手机在线高清| 国产高清毛片区1区二区三区| 日韩欧美亚洲一区二区三区 | 欧美日韩一区二区三区四区在线观看| 亚洲五月综合激情综合久久| 久久夜色精品亚洲国产| 国产亚洲欧美精品在线观看| 一区二区三区在线观看淫| 亚洲国产精品综合久久网络| 国内成人午夜激情视频| 午夜精品久久99蜜桃| 亚洲国产传媒在线观看| 日韩大片一区二区三区在线观看 | 国产国产成人精品久久| 日本免费高清一区二区| 青青草日韩欧美在线观看| 欧美黄色一区二区三区精品| 国产女同一区二区三区久久| 最新国产精品欧美激情| 中文字幕在线感觉av| 国产亚洲精品一区二区三在线观看| 天堂在线精品亚洲综合网| 亚洲国产中日韩精品综合| 日本精品一区二区不卡| 亚洲成人福利免费网站| 国产91精品系列在线观看| 亚洲成人av在线蜜桃|