Segondè pèfòmans se youn nan kondisyon kle yo lè w ap travay ak gwo done. Nan depatman loading done nan Sberbank, nou ponpe prèske tout tranzaksyon yo nan Cloud Done ki baze sou Hadoop nou an, kidonk nou fè fas ak yon gwo koule enfòmasyon. Natirèlman, nou toujou ap chèche fason pou amelyore pèfòmans, epi kounye a nou vle di ou ki jan nou jere patch RegionServer HBase ak kliyan an HDFS, gras a ki nou te kapab siyifikativman ogmante vitès la nan operasyon lekti.
Sepandan, anvan ou ale nan sans nan amelyorasyon yo, li vo pale sou restriksyon ki, nan prensip, pa ka kontourne si ou chita sou yon HDD.
Poukisa HDD ak lekti rapid Random Access yo enkonpatib
Kòm ou konnen, HBase, ak anpil lòt baz done, estoke done nan blòk plizyè dizèn kilobyte nan gwosè. Pa default li se sou 64 KB. Koulye a, ann imajine ke nou bezwen jwenn sèlman 100 bytes epi nou mande HBase pou ban nou done sa yo lè l sèvi avèk yon sèten kle. Depi gwosè blòk nan HFiles se 64 KB, demann lan pral 640 fwa pi gwo (jis yon minit!) pase sa nesesè.
Apre sa, depi demann lan pral pase nan HDFS ak mekanis kachèt metadata li yo ShortCircuitCache (ki pèmèt aksè dirèk nan dosye), sa a mennen nan lekti deja 1 MB nan disk la. Sepandan, sa a ka ajiste ak paramèt la dfs.client.read.shortcircuit.buffer.size epi nan anpil ka li fè sans pou redwi valè sa a, pa egzanp a 126 KB.
Ann di nou fè sa, men anplis, lè nou kòmanse li done atravè java api a, tankou fonksyon tankou FileChannel.read epi mande sistèm operasyon an li kantite done espesifye, li li "jis nan ka" 2 fwa plis. , i.e. 256 KB nan ka nou an. Sa a se paske java pa gen yon fason fasil pou mete drapo FADV_RANDOM pou anpeche konpòtman sa a.
Kòm yon rezilta, jwenn 100 bytes nou yo, 2600 fwa plis li anba kapo a. Li ta sanble ke solisyon an se evidan, se pou yo redwi gwosè blòk la nan yon kilobyte, mete drapo a mansyone ak jwenn gwo akselerasyon Syèk Limyè. Men pwoblèm nan se ke lè nou redwi gwosè blòk la pa 2 fwa, nou menm tou nou redwi kantite bytes li pou chak inite tan pa 2 fwa.
Ou ka jwenn kèk benefis nan mete drapo FADV_RANDOM la, men se sèlman ak gwo milti-threading ak yon gwosè blòk 128 KB, men sa a se yon maksimòm de yon koup de dizèn de pousan:
Tès yo te fèt sou 100 fichye, chak 1 GB nan gwosè ak ki chita sou 10 HDD.
Ann kalkile sou kisa nou ka konte, nan prensip, nan vitès sa a:
Ann di nou li nan 10 disk nan yon vitès 280 MB/sec, i.e. 3 milyon fwa 100 bytes. Men, jan nou sonje, done nou bezwen yo se 2600 fwa mwens pase sa yo li. Kidonk, nou divize 3 milyon pa 2600 epi jwenn 1100 dosye pou chak segonn.
Depresyon, pa vre? Sa se lanati Aksè o aza aksè a done sou HDD a - kèlkeswa gwosè blòk la. Sa a se limit fizik aksè o aza epi okenn baz done pa ka peze plis nan kondisyon sa yo.
Lè sa a, ki jan baz done reyalize pi gwo vitès? Pou reponn kesyon sa a, ann gade sa k ap pase nan foto sa a:
Isit la nou wè ke pou premye minit yo vitès la se reyèlman sou yon mil dosye pou chak segonn. Sepandan, pi lwen, akòz lefèt ke anpil plis li pase sa yo te mande a, done yo fini nan buff / kachèt nan sistèm nan opere (linux) ak vitès la ogmante nan yon plis desan 60 mil pou chak segonn.
Kidonk, plis nou pral fè fas ak akselere aksè sèlman nan done ki nan kachèt OS oswa ki sitiye nan aparèy depo SSD / NVMe ki gen vitès aksè konparab.
Nan ka nou an, nou pral fè tès sou yon ban 4 sèvè, chak nan yo chaje jan sa a:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 fil.
Memwa: 730 GB.
vèsyon java: 1.8.0_111
Ak isit la pwen kle a se kantite done nan tab yo ki bezwen li. Reyalite a se ke si ou li done ki sòti nan yon tab ki se antyèman mete nan kachèt la HBase, Lè sa a, li pa pral menm vini nan lekti nan buff / kachèt sistèm operasyon an. Paske HBase pa default asiyen 40% nan memwa nan yon estrikti ki rele BlockCache. Esansyèlman sa a se yon ConcurrentHashMap, kote kle a se non dosye a + konpanse nan blòk la, ak valè a se done aktyèl la nan konpanse sa a.
Kidonk, lè li sèlman nan estrikti sa a, nou , tankou yon milyon demann pou chak segonn. Men, an n imajine ke nou pa ka asiyen dè santèn de gigaocte nan memwa jis pou bezwen baz done, paske gen yon anpil nan lòt bagay itil ki kouri sou serveurs sa yo.
Pou egzanp, nan ka nou an, volim nan BlockCache sou yon sèl RS se sou 12 GB. Nou te ateri de RS sou yon sèl ne, i.e. 96 GB yo atribye ba pou BlockCache sou tout nœuds. Epi gen anpil fwa plis done, pou egzanp, kite li dwe 4 tab, 130 rejyon yo chak, nan ki dosye yo se 800 MB nan gwosè, konprese pa FAST_DIFF, i.e. yon total de 410 GB (sa a se pi bon kalite done, sa vle di san yo pa pran an kont faktè replikasyon an).
Kidonk, BlockCache se sèlman apeprè 23% nan volim total done ak sa a se pi pre kondisyon reyèl yo nan sa yo rele BigData. Lè sa a se kote plezi a kòmanse - paske evidamman, mwens kachèt frape, pi mal pèfòmans lan. Apre yo tout, si ou rate, ou pral oblije fè anpil travay - i.e. desann nan apèl fonksyon sistèm. Sepandan, sa a pa ka evite, kidonk kite a gade nan yon aspè konplètman diferan - sa k ap pase nan done yo andedan kachèt la?
Ann senplifye sitiyasyon an epi sipoze ke nou gen yon kachèt ki adapte sèlman 1 objè. Men yon egzanp sou sa ki pral rive lè nou eseye travay ak yon volim done 3 fwa pi gwo pase kachèt la, nou pral oblije:
1. Mete blòk 1 nan kachèt
2. Retire blòk 1 nan kachèt
3. Mete blòk 2 nan kachèt
4. Retire blòk 2 nan kachèt
5. Mete blòk 3 nan kachèt
5 aksyon fini! Sepandan, sitiyasyon sa a pa ka rele nòmal, an reyalite, nou ap fòse HBase fè yon pakèt travay konplètman initil. Li toujou ap li done ki soti nan kachèt OS la, li mete l nan BlockCache, sèlman pou l jete l deyò prèske imedyatman paske yon nouvo pòsyon done te rive. Animasyon an nan kòmansman an nan pòs la montre sans nan pwoblèm nan - Pèseptè fatra ap ale nan echèl, atmosfè a ap chofe, ti Greta nan byen lwen ak cho Syèd ap vin fache. Epi nou moun IT reyèlman pa renmen li lè timoun yo tris, kidonk nou kòmanse reflechi sou sa nou ka fè sou li.
E si ou mete pa tout blòk nan kachèt la, men se sèlman yon sèten pousantaj nan yo, pou kachèt la pa debòde? Ann kòmanse tou senpleman ajoute jis kèk liy kòd nan kòmansman fonksyon an pou mete done nan BlockCache:
public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
return;
}
}
...
Pwen an isit la se sa ki annapre yo: konpanse se pozisyon blòk la nan dosye a ak dènye chif li yo distribye owaza e respire soti nan 00 a 99. Se poutèt sa, nou pral sèlman sote sa yo ki tonbe nan seri nou bezwen an.
Pou egzanp, mete cacheDataBlockPercent = 20 epi wè sa k ap pase:
Rezilta a se evidan. Nan graf ki anba yo, li vin klè poukisa yon akselerasyon konsa te fèt - nou sove yon anpil nan resous GC san yo pa fè travay la Sisyphean nan mete done nan kachèt la sèlman imedyatman jete yo nan drenaj la nan chen Marsyen yo:
An menm tan an, itilizasyon CPU ogmante, men li pi piti pase pwodiktivite:
Li se tou vo sonje ke blòk yo ki estoke nan BlockCache yo diferan. Pifò, apeprè 95%, se done tèt li. Ak rès la se metadata, tankou Bloom filtè oswa LEAF_INDEX ak . Done sa yo pa ase, men li trè itil, paske anvan ou jwenn aksè nan done yo dirèkteman, HBase vire nan meta a pou konprann si li nesesè pou chèche isit la pi lwen epi, si se konsa, ki kote egzakteman blòk enterè a sitiye.
Se poutèt sa, nan kòd la nou wè yon kondisyon chèk buf.getBlockType().isData() ak gras a meta sa a, nou pral kite li nan kachèt la nan nenpòt ka.
Koulye a, kite a ogmante chaj la ak yon ti kras sere boulon moute karakteristik la nan yon sèl ale. Nan premye tès la nou te fè pousantaj koupe a = 20 ak BlockCache te yon ti kras underutilized. Koulye a, ann mete l sou 23% epi ajoute 100 fil chak 5 minit pou wè nan ki pwen saturation rive:
Isit la nou wè ke vèsyon orijinal la prèske imedyatman frape plafon an nan apeprè 100 mil demann pou chak segonn. Lè nou konsidere ke patch la bay yon akselerasyon ki rive jiska 300 mil. An menm tan an, li klè ke plis akselerasyon pa tèlman "gratis" ankò; itilizasyon CPU ap ogmante tou.
Sepandan, sa a se pa yon solisyon trè elegant, depi nou pa konnen davans ki pousantaj nan blòk bezwen yo dwe kachèt, li depann de pwofil la chaj. Se poutèt sa, yon mekanis te aplike otomatikman ajiste paramèt sa a depann sou aktivite a nan operasyon lekti.
Twa opsyon yo te ajoute pou kontwole sa a:
hbase.lru.cache.heavy.eviction.count.limit — fikse konbyen fwa pwosesis degèpisman done ki soti nan kachèt la ta dwe kouri anvan nou kòmanse itilize optimize (sa vle di sote blòk). Pa default li egal a MAX_INT = 2147483647 e an reyalite vle di ke karakteristik nan pa janm ap kòmanse travay ak valè sa a. Paske pwosesis degèpisman an kòmanse chak 5 - 10 segonn (sa depann de chaj la) ak 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 ane. Sepandan, nou ka mete paramèt sa a a 0 epi fè karakteristik nan travay imedyatman apre lansman.
Sepandan, gen tou yon chaj nan paramèt sa a. Si chaj nou an se konsa ke lekti kout tèm (di pandan jounen an) ak lekti alontèm (nan mitan lannwit) yo toujou ap antremele, Lè sa a, nou ka asire w ke karakteristik nan vire sou sèlman lè operasyon lekti long yo nan pwogrè.
Pou egzanp, nou konnen ke lekti kout tèm anjeneral dire apeprè 1 minit. Pa gen okenn nesesite yo kòmanse voye jete blòk, kachèt la pa pral gen tan vin demode ak Lè sa a, nou ka mete paramèt sa a egal a, pou egzanp, 10. Sa ap mennen nan lefèt ke optimize a ap kòmanse travay sèlman lè long- tèm lekti aktif te kòmanse, i.e. nan 100 segonn. Kidonk, si nou gen yon lekti kout tèm, Lè sa a, tout blòk yo pral antre nan kachèt la epi yo pral disponib (eksepte pou sa yo ki pral degèpi pa algorithm estanda a). Men, lè nou fè lekti alontèm, karakteristik nan vire sou epi nou ta gen pi wo pèfòmans.
hbase.lru.cache.heavy.eviction.mb.size.limit — fikse konbyen megabyte nou ta renmen mete nan kachèt la (e, nan kou, degèpi) nan 10 segonn. Karakteristik la pral eseye rive jwenn valè sa a epi kenbe li. Pwen an se sa a: si nou mete gigaocte nan kachèt la, Lè sa a, nou pral gen degèpi gigaocte, ak sa a, jan nou te wè pi wo a, se trè chè. Sepandan, ou pa ta dwe eseye mete li twò piti, paske sa a pral lakòz mòd sote blòk la soti prematireman. Pou serveurs pwisan (apeprè 20-40 nwayo fizik), li pi bon yo mete sou 300-400 MB. Pou klas presegondè a (~10 nwayo) 200-300 MB. Pou sistèm fèb (2-5 nwayo) 50-100 MB ka nòmal (pa teste sou sa yo).
Ann gade nan ki jan sa a fonksyone: ann di nou mete hbase.lru.cache.heavy.eviction.mb.size.limit = 500, gen yon kalite chaj (lekti) ak Lè sa a, chak ~ 10 segonn nou kalkile konbyen byte yo te. degèpi lè l sèvi avèk fòmil la:
Anlè = Freed Bytes Sòm (MB) * 100 / Limit (MB) - 100;
Si an reyalite 2000 MB yo te degèpi, Lè sa a, Overhead egal a:
2000 * 100 / 500 - 100 = 300%
Algoritm yo eseye kenbe pa plis pase kèk dizèn de pousan, kidonk karakteristik nan ap diminye pousantaj nan blòk kachèt, kidonk mete ann aplikasyon yon mekanis oto-akor.
Sepandan, si chaj la tonbe, an n di sèlman 200 MB yo degèpi ak Overhead vin negatif (sa yo rele depase):
200 * 100 / 500 - 100 = -60%
Okontrè, karakteristik la ap ogmante pousantaj nan blòk kachèt jiskaske Overhead vin pozitif.
Anba la a se yon egzanp sou fason sa a sanble sou done reyèl. Pa gen okenn nesesite pou eseye rive nan 0%, li enposib. Li trè bon lè li se sou 30 - 100%, sa a ede pou fè pou evite twò bonè sòti nan mòd nan optimize pandan vag kout tèm.
hbase.lru.cache.heavy.eviction.overhead.coefficient — fikse konbyen vit nou ta renmen jwenn rezilta a. Si nou konnen pou asire ke lekti nou yo se sitou long epi yo pa vle tann, nou ka ogmante rapò sa a epi jwenn pèfòmans segondè pi vit.
Pou egzanp, nou mete koyefisyan sa a = 0.01. Sa vle di ke Overhead (gade pi wo a) pral miltipliye pa nimewo sa a pa rezilta a ki kapab lakòz epi pousantaj nan blòk kach yo ap redwi. Ann sipoze ke anlè = 300% ak koyefisyan = 0.01, Lè sa a, pousantaj nan blòk kachèt yo pral redwi pa 3%.
Yon lojik "Backpressure" ki sanble tou aplike pou valè negatif Overhead (depase). Piske fluctuations kout tèm nan volim nan lekti ak degèpisman yo toujou posib, mekanis sa a pèmèt ou evite twò bonè sòti nan mòd nan optimize. Backpressure gen yon lojik Envèse: pi fò depasaj la, plis blòk yo kach.
Kòd aplikasyon
LruBlockCache cache = this.cache.get();
if (cache == null) {
break;
}
freedSumMb += cache.evict()/1024/1024;
/*
* Sometimes we are reading more data than can fit into BlockCache
* and it is the cause a high rate of evictions.
* This in turn leads to heavy Garbage Collector works.
* So a lot of blocks put into BlockCache but never read,
* but spending a lot of CPU resources.
* Here we will analyze how many bytes were freed and decide
* decide whether the time has come to reduce amount of caching blocks.
* It help avoid put too many blocks into BlockCache
* when evict() works very active and save CPU for other jobs.
* More delails: https://issues.apache.org/jira/browse/HBASE-23887
*/
// First of all we have to control how much time
// has passed since previuos evict() was launched
// This is should be almost the same time (+/- 10s)
// because we get comparable volumes of freed bytes each time.
// 10s because this is default period to run evict() (see above this.wait)
long stopTime = System.currentTimeMillis();
if ((stopTime - startTime) > 1000 * 10 - 1) {
// Here we have to calc what situation we have got.
// We have the limit "hbase.lru.cache.heavy.eviction.bytes.size.limit"
// and can calculte overhead on it.
// We will use this information to decide,
// how to change percent of caching blocks.
freedDataOverheadPercent =
(int) (freedSumMb * 100 / cache.heavyEvictionMbSizeLimit) - 100;
if (freedSumMb > cache.heavyEvictionMbSizeLimit) {
// Now we are in the situation when we are above the limit
// But maybe we are going to ignore it because it will end quite soon
heavyEvictionCount++;
if (heavyEvictionCount > cache.heavyEvictionCountLimit) {
// It is going for a long time and we have to reduce of caching
// blocks now. So we calculate here how many blocks we want to skip.
// It depends on:
// 1. Overhead - if overhead is big we could more aggressive
// reducing amount of caching blocks.
// 2. How fast we want to get the result. If we know that our
// heavy reading for a long time, we don't want to wait and can
// increase the coefficient and get good performance quite soon.
// But if we don't sure we can do it slowly and it could prevent
// premature exit from this mode. So, when the coefficient is
// higher we can get better performance when heavy reading is stable.
// But when reading is changing we can adjust to it and set
// the coefficient to lower value.
int change =
(int) (freedDataOverheadPercent * cache.heavyEvictionOverheadCoefficient);
// But practice shows that 15% of reducing is quite enough.
// We are not greedy (it could lead to premature exit).
change = Math.min(15, change);
change = Math.max(0, change); // I think it will never happen but check for sure
// So this is the key point, here we are reducing % of caching blocks
cache.cacheDataBlockPercent -= change;
// If we go down too deep we have to stop here, 1% any way should be.
cache.cacheDataBlockPercent = Math.max(1, cache.cacheDataBlockPercent);
}
} else {
// Well, we have got overshooting.
// Mayby it is just short-term fluctuation and we can stay in this mode.
// It help avoid permature exit during short-term fluctuation.
// If overshooting less than 90%, we will try to increase the percent of
// caching blocks and hope it is enough.
if (freedSumMb >= cache.heavyEvictionMbSizeLimit * 0.1) {
// Simple logic: more overshooting - more caching blocks (backpressure)
int change = (int) (-freedDataOverheadPercent * 0.1 + 1);
cache.cacheDataBlockPercent += change;
// But it can't be more then 100%, so check it.
cache.cacheDataBlockPercent = Math.min(100, cache.cacheDataBlockPercent);
} else {
// Looks like heavy reading is over.
// Just exit form this mode.
heavyEvictionCount = 0;
cache.cacheDataBlockPercent = 100;
}
}
LOG.info("BlockCache evicted (MB): {}, overhead (%): {}, " +
"heavy eviction counter: {}, " +
"current caching DataBlock (%): {}",
freedSumMb, freedDataOverheadPercent,
heavyEvictionCount, cache.cacheDataBlockPercent);
freedSumMb = 0;
startTime = stopTime;
}
Ann gade kounye a tout bagay sa yo lè l sèvi avèk yon egzanp reyèl. Nou gen script tès sa a:
- Ann kòmanse fè Scan (25 fil, pakèt = 100)
- Apre 5 minit, ajoute milti-obtient (25 fil, pakèt = 100)
- Apre 5 minit, fèmen milti-obtient (sèlman eskanè rete ankò)
Nou fè de kouri, premye hbase.lru.cache.heavy.eviction.count.limit = 10000 (ki aktyèlman enfim karakteristik nan), ak Lè sa a, mete limit = 0 (pèmèt li).
Nan mòso bwa ki anba yo nou wè ki jan karakteristik nan vire sou ak reset Overshooting a 14-71%. De tan zan tan chaj la diminye, ki vire sou Backpressure ak HBase kachèt plis blòk ankò.
Log RegionServer
degèpi (MB): 0, rapò 0.0, anlè (%): -100, kontè degèpisman lou: 0, aktyèl kachèt DataBlock (%): 100
degèpi (MB): 0, rapò 0.0, anlè (%): -100, kontè degèpisman lou: 0, aktyèl kachèt DataBlock (%): 100
degèpisman (MB): 2170, rapò 1.09, anlè (%): 985, kontwa degèpisman lou: 1, kachèt aktyèl DataBlock (%): 91 < kòmanse
degèpisman (MB): 3763, rapò 1.08, anlè (%): 1781, kontwa degèpisman lou: 2, kachèt aktyèl DataBlock (%): 76
degèpisman (MB): 3306, rapò 1.07, anlè (%): 1553, kontwa degèpisman lou: 3, kachèt aktyèl DataBlock (%): 61
degèpisman (MB): 2508, rapò 1.06, anlè (%): 1154, kontwa degèpisman lou: 4, kachèt aktyèl DataBlock (%): 50
degèpisman (MB): 1824, rapò 1.04, anlè (%): 812, kontwa degèpisman lou: 5, kachèt aktyèl DataBlock (%): 42
degèpisman (MB): 1482, rapò 1.03, anlè (%): 641, kontwa degèpisman lou: 6, kachèt aktyèl DataBlock (%): 36
degèpisman (MB): 1140, rapò 1.01, anlè (%): 470, kontwa degèpisman lou: 7, kachèt aktyèl DataBlock (%): 32
degèpisman (MB): 913, rapò 1.0, anlè (%): 356, kontwa degèpisman lou: 8, kachèt aktyèl DataBlock (%): 29
degèpisman (MB): 912, rapò 0.89, anlè (%): 356, kontwa degèpisman lou: 9, kachèt aktyèl DataBlock (%): 26
degèpisman (MB): 684, rapò 0.76, anlè (%): 242, kontwa degèpisman lou: 10, kachèt aktyèl DataBlock (%): 24
degèpisman (MB): 684, rapò 0.61, anlè (%): 242, kontwa degèpisman lou: 11, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 456, rapò 0.51, anlè (%): 128, kontwa degèpisman lou: 12, kachèt aktyèl DataBlock (%): 21
degèpisman (MB): 456, rapò 0.42, anlè (%): 128, kontwa degèpisman lou: 13, kachèt aktyèl DataBlock (%): 20
degèpisman (MB): 456, rapò 0.33, anlè (%): 128, kontwa degèpisman lou: 14, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 15, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 342, rapò 0.32, anlè (%): 71, kontwa degèpisman lou: 16, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 342, rapò 0.31, anlè (%): 71, kontwa degèpisman lou: 17, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.3, anlè (%): 14, kontwa degèpisman lou: 18, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.29, anlè (%): 14, kontwa degèpisman lou: 19, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.27, anlè (%): 14, kontwa degèpisman lou: 20, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.25, anlè (%): 14, kontwa degèpisman lou: 21, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.24, anlè (%): 14, kontwa degèpisman lou: 22, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.22, anlè (%): 14, kontwa degèpisman lou: 23, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.21, anlè (%): 14, kontwa degèpisman lou: 24, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.2, anlè (%): 14, kontwa degèpisman lou: 25, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 228, rapò 0.17, anlè (%): 14, kontwa degèpisman lou: 26, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 456, rapò 0.17, anlè (%): 128, kontwa degèpisman lou: 27, kachèt aktyèl DataBlock (%): 18 < te ajoute vin (men tab la menm)
degèpisman (MB): 456, rapò 0.15, anlè (%): 128, kontwa degèpisman lou: 28, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 342, rapò 0.13, anlè (%): 71, kontwa degèpisman lou: 29, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 342, rapò 0.11, anlè (%): 71, kontwa degèpisman lou: 30, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 342, rapò 0.09, anlè (%): 71, kontwa degèpisman lou: 31, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 228, rapò 0.08, anlè (%): 14, kontwa degèpisman lou: 32, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 228, rapò 0.07, anlè (%): 14, kontwa degèpisman lou: 33, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 228, rapò 0.06, anlè (%): 14, kontwa degèpisman lou: 34, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 228, rapò 0.05, anlè (%): 14, kontwa degèpisman lou: 35, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 228, rapò 0.05, anlè (%): 14, kontwa degèpisman lou: 36, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 228, rapò 0.04, anlè (%): 14, kontwa degèpisman lou: 37, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 109, rapò 0.04, anlè (%): -46, kontwa degèpisman lou: 37, kachèt aktyèl DataBlock (%): 22 <back pressure
degèpisman (MB): 798, rapò 0.24, anlè (%): 299, kontwa degèpisman lou: 38, kachèt aktyèl DataBlock (%): 20
degèpisman (MB): 798, rapò 0.29, anlè (%): 299, kontwa degèpisman lou: 39, kachèt aktyèl DataBlock (%): 18
degèpisman (MB): 570, rapò 0.27, anlè (%): 185, kontwa degèpisman lou: 40, kachèt aktyèl DataBlock (%): 17
degèpisman (MB): 456, rapò 0.22, anlè (%): 128, kontwa degèpisman lou: 41, kachèt aktyèl DataBlock (%): 16
degèpisman (MB): 342, rapò 0.16, anlè (%): 71, kontwa degèpisman lou: 42, kachèt aktyèl DataBlock (%): 16
degèpisman (MB): 342, rapò 0.11, anlè (%): 71, kontwa degèpisman lou: 43, kachèt aktyèl DataBlock (%): 16
degèpisman (MB): 228, rapò 0.09, anlè (%): 14, kontwa degèpisman lou: 44, kachèt aktyèl DataBlock (%): 16
degèpisman (MB): 228, rapò 0.07, anlè (%): 14, kontwa degèpisman lou: 45, kachèt aktyèl DataBlock (%): 16
degèpisman (MB): 228, rapò 0.05, anlè (%): 14, kontwa degèpisman lou: 46, kachèt aktyèl DataBlock (%): 16
degèpisman (MB): 222, rapò 0.04, anlè (%): 11, kontwa degèpisman lou: 47, kachèt aktyèl DataBlock (%): 16
degèpisman (MB): 104, rapò 0.03, anlè (%): -48, kontwa degèpisman lou: 47, kachèt aktyèl DataBlock (%): 21 <interruption obtient
degèpisman (MB): 684, rapò 0.2, anlè (%): 242, kontwa degèpisman lou: 48, kachèt aktyèl DataBlock (%): 19
degèpisman (MB): 570, rapò 0.23, anlè (%): 185, kontwa degèpisman lou: 49, kachèt aktyèl DataBlock (%): 18
degèpisman (MB): 342, rapò 0.22, anlè (%): 71, kontwa degèpisman lou: 50, kachèt aktyèl DataBlock (%): 18
degèpisman (MB): 228, rapò 0.21, anlè (%): 14, kontwa degèpisman lou: 51, kachèt aktyèl DataBlock (%): 18
degèpisman (MB): 228, rapò 0.2, anlè (%): 14, kontwa degèpisman lou: 52, kachèt aktyèl DataBlock (%): 18
degèpisman (MB): 228, rapò 0.18, anlè (%): 14, kontwa degèpisman lou: 53, kachèt aktyèl DataBlock (%): 18
degèpisman (MB): 228, rapò 0.16, anlè (%): 14, kontwa degèpisman lou: 54, kachèt aktyèl DataBlock (%): 18
degèpisman (MB): 228, rapò 0.14, anlè (%): 14, kontwa degèpisman lou: 55, kachèt aktyèl DataBlock (%): 18
degèpisman (MB): 112, rapò 0.14, anlè (%): -44, kontwa degèpisman lou: 55, kachèt aktyèl DataBlock (%): 23 <back pressure
degèpisman (MB): 456, rapò 0.26, anlè (%): 128, kontwa degèpisman lou: 56, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.31, anlè (%): 71, kontwa degèpisman lou: 57, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 58, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 59, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 60, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 61, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 62, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 63, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.32, anlè (%): 71, kontwa degèpisman lou: 64, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 65, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 66, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.32, anlè (%): 71, kontwa degèpisman lou: 67, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 68, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.32, anlè (%): 71, kontwa degèpisman lou: 69, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.32, anlè (%): 71, kontwa degèpisman lou: 70, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 71, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 72, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 73, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 74, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 75, kachèt aktyèl DataBlock (%): 22
degèpisman (MB): 342, rapò 0.33, anlè (%): 71, kontwa degèpisman lou: 76, kachèt aktyèl DataBlock (%): 22
degèpi (MB): 21, rapò 0.33, anlè (%): -90, kontè degèpisman lou: 76, aktyèl kachèt DataBlock (%): 32
degèpi (MB): 0, rapò 0.0, anlè (%): -100, kontè degèpisman lou: 0, aktyèl kachèt DataBlock (%): 100
degèpi (MB): 0, rapò 0.0, anlè (%): -100, kontè degèpisman lou: 0, aktyèl kachèt DataBlock (%): 100
Yo te bezwen analiz yo pou montre menm pwosesis la nan fòm yon graf nan relasyon ki genyen ant de seksyon kachèt - sèl (kote blòk ki pa janm te mande anvan) ak milti (done "mande" omwen yon fwa yo estoke isit la):
Epi finalman, kisa operasyon paramèt yo sanble nan fòm yon graf. Pou konparezon, kachèt la te konplètman etenn nan kòmansman an, Lè sa a, HBase te lanse ak kachèt ak retade kòmansman an nan travay optimize pa 5 minit (30 sik degèpisman).
Ou ka jwenn tout kòd nan Pull Request sou github.
Sepandan, 300 mil lekti pou chak segonn se pa tout sa ki ka reyalize sou pyès ki nan konpitè sa a nan kondisyon sa yo. Reyalite a se ke lè ou bezwen jwenn aksè nan done atravè HDFS, yo itilize mekanis ShortCircuitCache (ki refere yo kòm SSC), ki pèmèt ou jwenn aksè nan done yo dirèkteman, evite entèraksyon rezo a.
Profilage te montre ke byenke mekanis sa a bay yon gwo benefis, li tou nan kèk pwen vin tounen yon bouche, paske prèske tout operasyon lou rive andedan yon seri, ki mennen nan bloke pi fò nan tan an.
Lè nou reyalize sa a, nou reyalize ke pwoblèm nan ka kontourne pa kreye yon etalaj de SSC endepandan:
private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
this.shortCircuitCache[i] = new ShortCircuitCache(…);
Apre sa, travay avèk yo, eksepte entèseksyon tou nan dènye chif konpanse a:
public ShortCircuitCache getShortCircuitCache(long idx) {
return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}
Koulye a, ou ka kòmanse tès la. Pou fè sa, nou pral li dosye ki soti nan HDFS ak yon senp aplikasyon milti-threaded. Mete paramèt yo:
conf.set("dfs.client.read.shortcircuit", "true");
conf.set("dfs.client.read.shortcircuit.buffer.size", "65536"); // по дефолту = 1 МБ и это сильно замедляет чтение, поэтому лучше привести в соответствие к реальным нуждам
conf.set("dfs.client.short.circuit.num", num); // от 1 до 10
Epi jis li dosye yo:
FSDataInputStream in = fileSystem.open(path);
for (int i = 0; i < count; i++) {
position += 65536;
if (position > 900000000)
position = 0L;
int res = in.read(position, byteBuffer, 0, 65536);
}
Kòd sa a egzekite nan fil separe epi nou pral ogmante kantite fichye li yo ansanm (ki soti nan 10 a 200 - aks orizontal) ak kantite kachèt (ki soti nan 1 a 10 - grafik). Aks vètikal la montre akselerasyon ki soti nan yon ogmantasyon nan SSC parapò ak ka a lè gen yon sèl kachèt.
Ki jan yo li graf la: Tan an ekzekisyon pou 100 mil lekti nan blòk 64 KB ak yon sèl kachèt mande pou 78 segonn. Lè nou konsidere ke ak 5 kachèt li pran 16 segonn. Moun sa yo. gen yon akselerasyon ~ 5 fwa. Kòm ou ka wè nan graf la, efè a pa trè aparan pou yon ti kantite lekti paralèl, li kòmanse jwe yon wòl aparan lè gen plis pase lekti fil 50. Li se tou aparan ke ogmante kantite SSC soti nan 6. ak pi wo a bay yon ogmantasyon siyifikativman pi piti pèfòmans.
Remak 1: depi rezilta tès yo byen temèt (gade anba a), yo te fè 3 kouri ak valè ki kapab lakòz yo te mwayèn.
Remak 2: Pwofi nan pèfòmans nan konfigirasyon aksè o aza se menm bagay la, byenke aksè nan tèt li se yon ti kras pi dousman.
Sepandan, li nesesè klarifye ke, kontrèman ak ka a ak HBase, akselerasyon sa a pa toujou gratis. Isit la nou "déblotché" kapasite CPU a pou fè travay plis, olye pou yo pandye sou kadna.
Isit la ou ka obsève ke, an jeneral, yon ogmantasyon nan kantite kachèt bay yon ogmantasyon apeprè pwopòsyonèl nan itilizasyon CPU. Sepandan, gen yon ti kras plis konbinezon genyen.
Pou egzanp, an n pran yon gade pi pre nan anviwònman an SSC = 3. Ogmantasyon nan pèfòmans sou seri a se apeprè 3.3 fwa. Anba a se rezilta yo nan tout twa kouri separe.
Pandan ke konsomasyon CPU ogmante pa apeprè 2.8 fwa. Diferans lan pa twò gwo, men ti Greta deja kontan e li gendwa gen tan ale lekòl epi pran leson.
Kidonk, sa a pral gen yon efè pozitif pou nenpòt zouti ki sèvi ak aksè esansyèl nan HDFS (pa egzanp Spark, elatriye), depi kòd aplikasyon an lejè (sa vle di ploge a se sou bò kliyan HDFS) epi gen pouvwa CPU gratis. . Pou tcheke, ann teste ki efè itilizasyon konbine nan optimize BlockCache ak akor SSC pou lekti nan HBase pral genyen.
Li ka wè ke nan kondisyon sa yo efè a se pa menm jan ak nan tès rafine (lekti san okenn pwosesis), men li se byen posib yo peze soti yon lòt 80K isit la. Ansanm, tou de optimize bay jiska 4x vitès.
Yo te fè yon PR tou pou optimize sa a , ki te fizyone ak fonksyonalite sa a ap disponib nan degaje pwochen.
Epi finalman, li te enteresan yo konpare pèfòmans nan lekti nan yon baz done menm jan an gwo kolòn, Cassandra ak HBase.
Pou fè sa, nou te lanse sikonstans sèvis piblik estanda tès chaj YCSB nan de lame (800 fil an total). Sou bò sèvè a - 4 ka nan RegionServer ak Cassandra sou 4 lame (pa sa yo kote kliyan yo ap kouri, pou fè pou evite enfliyans yo). Lekti yo soti nan tablo gwosè:
HBase - 300 GB sou HDFS (100 GB done pi bon kalite)
Cassandra - 250 GB (faktè replikasyon = 3)
Moun sa yo. volim nan te apeprè menm bagay la (nan HBase yon ti kras plis).
Paramèt HBase:
dfs.client.short.circuit.num = 5 (HDFS kliyan optimize)
hbase.lru.cache.heavy.eviction.count.limit = 30 - sa vle di patch la ap kòmanse travay apre 30 degèpisman (~5 minit)
hbase.lru.cache.heavy.eviction.mb.size.limit = 300 — volim sib nan kachèt ak degèpisman
Jounal YCSB yo te analize ak konpile nan graf Excel:
Kòm ou ka wè, optimize sa yo fè li posib pou konpare pèfòmans baz done sa yo nan kondisyon sa yo epi reyalize 450 mil lekti pou chak segonn.
Nou espere enfòmasyon sa yo ka itil yon moun pandan batay enteresan pou pwodiktivite a.
Sous: www.habr.com