పెద్ద డేటాతో పనిచేసేటప్పుడు అధిక పనితీరు కీలక అవసరాలలో ఒకటి. స్బేర్‌బ్యాంక్‌లోని డేటా లోడింగ్ విభాగంలో, మేము దాదాపు అన్ని లావాదేవీలను మా హడూప్-ఆధారిత డేటా క్లౌడ్‌లోకి పంపిస్తాము మరియు అందువల్ల పెద్ద మొత్తంలో సమాచారంతో వ్యవహరిస్తాము. సహజంగానే, మేము ఎల్లప్పుడూ పనితీరును మెరుగుపరచడానికి మార్గాల కోసం వెతుకుతున్నాము మరియు ఇప్పుడు మేము రీజియన్‌సర్వర్ హెచ్‌బేస్ మరియు హెచ్‌డిఎఫ్‌ఎస్ క్లయింట్‌ను ఎలా ప్యాచ్ చేయగలిగామో మీకు చెప్పాలనుకుంటున్నాము, దీనికి ధన్యవాదాలు మేము రీడ్ ఆపరేషన్ల వేగాన్ని గణనీయంగా పెంచగలిగాము.
అయితే, మెరుగుదలల సారాంశానికి వెళ్లే ముందు, మీరు HDDలో కూర్చుంటే సూత్రప్రాయంగా, తప్పించుకోలేని పరిమితుల గురించి మాట్లాడటం విలువ.
HDD మరియు వేగవంతమైన రాండమ్ యాక్సెస్ రీడ్‌లు ఎందుకు అనుకూలంగా లేవు
మీకు తెలిసినట్లుగా, HBase మరియు అనేక ఇతర డేటాబేస్‌లు, అనేక పదుల కిలోబైట్ల పరిమాణంలో ఉన్న బ్లాక్‌లలో డేటాను నిల్వ చేస్తాయి. డిఫాల్ట్‌గా ఇది దాదాపు 64 KB. ఇప్పుడు మనం కేవలం 100 బైట్‌లను మాత్రమే పొందాలి మరియు నిర్దిష్ట కీని ఉపయోగించి ఈ డేటాను మాకు అందించమని HBaseని అడుగుతాము. HFilesలో బ్లాక్ పరిమాణం 64 KB కాబట్టి, అభ్యర్థన అవసరమైన దానికంటే 640 రెట్లు పెద్దదిగా (ఒక్క నిమిషం!) ఉంటుంది.
తర్వాత, అభ్యర్థన HDFS మరియు దాని మెటాడేటా కాషింగ్ మెకానిజం ద్వారా వెళుతుంది కాబట్టి ShortCircuitCache (ఇది ఫైల్‌లకు ప్రత్యక్ష ప్రాప్యతను అనుమతిస్తుంది), ఇది డిస్క్ నుండి ఇప్పటికే 1 MBని చదవడానికి దారితీస్తుంది. అయితే, ఇది పారామీటర్‌తో సర్దుబాటు చేయబడుతుంది dfs.client.read.shortcircuit.buffer.size మరియు అనేక సందర్భాల్లో ఈ విలువను తగ్గించడానికి అర్ధమే, ఉదాహరణకు 126 KB.
మనం ఇలా చేద్దాం అనుకుందాం, అయితే అదనంగా, ఫైల్‌ఛానల్.రీడ్ వంటి ఫంక్షన్‌ల వంటి java api ద్వారా డేటాను చదవడం ప్రారంభించినప్పుడు మరియు పేర్కొన్న మొత్తం డేటాను చదవమని ఆపరేటింగ్ సిస్టమ్‌ను అడిగినప్పుడు, అది “కేవలం సందర్భంలో” 2 రెట్లు ఎక్కువ చదువుతుంది. , అనగా మా విషయంలో 256 KB. ఎందుకంటే ఈ ప్రవర్తనను నిరోధించడానికి FADV_RANDOM ఫ్లాగ్‌ను సెట్ చేయడానికి జావాకు సులభమైన మార్గం లేదు.
ఫలితంగా, మా 100 బైట్‌లను పొందడానికి, హుడ్ కింద 2600 రెట్లు ఎక్కువ చదవబడుతుంది. పరిష్కారం స్పష్టంగా ఉన్నట్లు అనిపిస్తుంది, బ్లాక్ పరిమాణాన్ని కిలోబైట్‌కు తగ్గించి, పేర్కొన్న జెండాను సెట్ చేసి, గొప్ప జ్ఞానోదయం త్వరణాన్ని పొందండి. కానీ ఇబ్బంది ఏమిటంటే, బ్లాక్ పరిమాణాన్ని 2 రెట్లు తగ్గించడం ద్వారా, మేము యూనిట్ సమయానికి చదివే బైట్‌ల సంఖ్యను 2 రెట్లు తగ్గిస్తాము.
FADV_RANDOM ఫ్లాగ్‌ని సెట్ చేయడం ద్వారా కొంత లాభం పొందవచ్చు, కానీ అధిక బహుళ-థ్రెడింగ్‌తో మరియు 128 KB బ్లాక్ పరిమాణంతో మాత్రమే పొందవచ్చు, అయితే ఇది గరిష్టంగా రెండు పదుల శాతం:
100 ఫైల్‌లపై పరీక్షలు జరిగాయి, ఒక్కొక్కటి 1 GB పరిమాణం మరియు 10 HDDలలో ఉన్నాయి.
సూత్రప్రాయంగా, ఈ వేగంతో మనం ఏమి లెక్కించవచ్చో లెక్కిద్దాం:
మనం 10 MB/sec వేగంతో 280 డిస్క్‌ల నుండి చదివామని అనుకుందాం, అనగా. 3 మిలియన్ సార్లు 100 బైట్లు. కానీ మనకు గుర్తున్నట్లుగా, మనకు అవసరమైన డేటా చదివిన దానికంటే 2600 రెట్లు తక్కువగా ఉంటుంది. ఈ విధంగా, మేము 3 మిలియన్లను 2600 ద్వారా విభజించి పొందుతాము సెకనుకు 1100 రికార్డులు.
నిరుత్సాహపరుస్తుంది, కాదా? అది ప్రకృతి రాండమ్ యాక్సెస్ HDDలో డేటాకు యాక్సెస్ - బ్లాక్ పరిమాణంతో సంబంధం లేకుండా. ఇది యాదృచ్ఛిక ప్రాప్యత యొక్క భౌతిక పరిమితి మరియు అటువంటి పరిస్థితులలో ఏ డేటాబేస్ కూడా ఎక్కువగా స్క్వీజ్ చేయదు.
డేటాబేస్‌లు అధిక వేగాన్ని ఎలా సాధిస్తాయి? ఈ ప్రశ్నకు సమాధానమివ్వడానికి, ఈ క్రింది చిత్రంలో ఏమి జరుగుతుందో చూద్దాం:
మొదటి కొన్ని నిమిషాల్లో వేగం నిజంగా సెకనుకు వెయ్యి రికార్డులు అని ఇక్కడ మనం చూస్తాము. అయితే, ఇంకా, అభ్యర్థించిన దానికంటే చాలా ఎక్కువ చదవబడినందున, డేటా ఆపరేటింగ్ సిస్టమ్ (linux) యొక్క బఫ్/కాష్‌లో ముగుస్తుంది మరియు వేగం సెకనుకు మరింత మంచి 60 వేలకు పెరుగుతుంది.
అందువల్ల, మేము OS కాష్‌లో ఉన్న లేదా పోల్చదగిన యాక్సెస్ వేగం గల SSD/NVMe నిల్వ పరికరాలలో ఉన్న డేటాకు మాత్రమే యాక్సెస్‌ని వేగవంతం చేయడంతో వ్యవహరిస్తాము.
మా విషయంలో, మేము 4 సర్వర్‌ల బెంచ్‌లో పరీక్షలను నిర్వహిస్తాము, వీటిలో ప్రతి ఒక్కటి క్రింది విధంగా ఛార్జ్ చేయబడుతుంది:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 థ్రెడ్‌లు.
మెమరీ: 730 GB.
జావా వెర్షన్: 1.8.0_111
మరియు ఇక్కడ ముఖ్య విషయం ఏమిటంటే చదవవలసిన పట్టికలలోని డేటా మొత్తం. వాస్తవం ఏమిటంటే, మీరు పూర్తిగా HBase కాష్‌లో ఉంచబడిన పట్టిక నుండి డేటాను చదివితే, అది ఆపరేటింగ్ సిస్టమ్ యొక్క బఫ్/కాష్ నుండి చదవడానికి కూడా రాదు. ఎందుకంటే HBase డిఫాల్ట్‌గా 40% మెమరీని BlockCache అనే స్ట్రక్చర్‌కు కేటాయిస్తుంది. ముఖ్యంగా ఇది ConcurrentHashMap, ఇక్కడ కీ ఫైల్ పేరు + బ్లాక్ ఆఫ్‌సెట్, మరియు విలువ ఈ ఆఫ్‌సెట్‌లోని వాస్తవ డేటా.
అందువలన, ఈ నిర్మాణం నుండి మాత్రమే చదివేటప్పుడు, మేము , సెకనుకు మిలియన్ అభ్యర్థనలు వంటివి. అయితే కేవలం డేటాబేస్ అవసరాల కోసం వందలకొద్దీ గిగాబైట్ల మెమరీని కేటాయించలేమని ఊహించుకుందాం, ఎందుకంటే ఈ సర్వర్‌లలో చాలా ఇతర ఉపయోగకరమైన విషయాలు నడుస్తున్నాయి.
ఉదాహరణకు, మా విషయంలో, ఒక RSలో BlockCache వాల్యూమ్ సుమారు 12 GB. మేము ఒక నోడ్‌పై రెండు RSలను ల్యాండ్ చేసాము, అనగా. 96 GB అన్ని నోడ్‌లలో BlockCache కోసం కేటాయించబడింది. మరియు అనేక రెట్లు ఎక్కువ డేటా ఉంది, ఉదాహరణకు, ఇది 4 పట్టికలు, ఒక్కొక్కటి 130 ప్రాంతాలుగా ఉండనివ్వండి, దీనిలో ఫైల్‌లు 800 MB పరిమాణంలో ఉంటాయి, FAST_DIFF ద్వారా కంప్రెస్ చేయబడతాయి, అనగా. మొత్తం 410 GB (ఇది స్వచ్ఛమైన డేటా, అనగా ప్రతిరూపణ కారకాన్ని పరిగణనలోకి తీసుకోకుండా).
అందువలన, BlockCache మొత్తం డేటా వాల్యూమ్‌లో కేవలం 23% మాత్రమే మరియు ఇది BigData అని పిలవబడే వాస్తవ పరిస్థితులకు చాలా దగ్గరగా ఉంటుంది. మరియు ఇక్కడే వినోదం ప్రారంభమవుతుంది - ఎందుకంటే స్పష్టంగా, తక్కువ కాష్ హిట్‌లు, పనితీరు అధ్వాన్నంగా ఉంటుంది. అన్ని తరువాత, మీరు మిస్ అయితే, మీరు చాలా పని చేయవలసి ఉంటుంది - అనగా. కాలింగ్ సిస్టమ్ ఫంక్షన్‌లకు వెళ్లండి. అయితే, దీనిని నివారించలేము, కాబట్టి పూర్తిగా భిన్నమైన అంశాన్ని చూద్దాం - కాష్ లోపల ఉన్న డేటాకు ఏమి జరుగుతుంది?
పరిస్థితిని సులభతరం చేసి, కేవలం 1 ఆబ్జెక్ట్‌కు సరిపోయే కాష్‌ని కలిగి ఉన్నామని అనుకుందాం. మేము కాష్ కంటే 3 రెట్లు పెద్ద డేటా వాల్యూమ్‌తో పని చేయడానికి ప్రయత్నించినప్పుడు ఏమి జరుగుతుందో ఇక్కడ ఒక ఉదాహరణ ఉంది, మేము వీటిని చేయాల్సి ఉంటుంది:
1. బ్లాక్ 1ని కాష్‌లో ఉంచండి
2. కాష్ నుండి బ్లాక్ 1ని తీసివేయండి
3. బ్లాక్ 2ని కాష్‌లో ఉంచండి
4. కాష్ నుండి బ్లాక్ 2ని తీసివేయండి
5. బ్లాక్ 3ని కాష్‌లో ఉంచండి
5 చర్యలు పూర్తయ్యాయి! అయితే, ఈ పరిస్థితిని సాధారణం అని పిలవలేము; వాస్తవానికి, మేము పూర్తిగా పనికిరాని పనిని చేయమని HBaseని బలవంతం చేస్తున్నాము. ఇది నిరంతరం OS కాష్ నుండి డేటాను చదువుతుంది, బ్లాక్‌కాష్‌లో ఉంచుతుంది, డేటా యొక్క కొత్త భాగం వచ్చినందున వెంటనే దాన్ని విసిరివేస్తుంది. పోస్ట్ ప్రారంభంలో ఉన్న యానిమేషన్ సమస్య యొక్క సారాంశాన్ని చూపుతుంది - చెత్త కలెక్టర్ స్థాయికి దూరంగా ఉంది, వాతావరణం వేడెక్కుతోంది, సుదూర మరియు వేడి స్వీడన్‌లో ఉన్న చిన్న గ్రేటా కలత చెందుతోంది. పిల్లలు విచారంగా ఉన్నప్పుడు మేము IT వ్యక్తులు నిజంగా ఇష్టపడరు, కాబట్టి మేము దాని గురించి ఏమి చేయగలమో ఆలోచించడం ప్రారంభిస్తాము.
మీరు కాష్‌లో అన్ని బ్లాక్‌లను ఉంచకుండా, వాటిలో కొంత శాతాన్ని మాత్రమే ఉంచినట్లయితే, కాష్ పొంగిపోకుండా ఉంటే? BlockCacheలో డేటాను ఉంచడం కోసం ఫంక్షన్ ప్రారంభంలో కేవలం కొన్ని పంక్తుల కోడ్‌ని జోడించడం ద్వారా ప్రారంభిద్దాం:
public void cacheBlock(BlockCacheKey cacheKey, Cacheable buf, boolean inMemory) {
if (cacheDataBlockPercent != 100 && buf.getBlockType().isData()) {
if (cacheKey.getOffset() % 100 >= cacheDataBlockPercent) {
return;
}
}
...
ఇక్కడ పాయింట్ క్రిందిది: ఆఫ్‌సెట్ అనేది ఫైల్‌లోని బ్లాక్ యొక్క స్థానం మరియు దాని చివరి అంకెలు 00 నుండి 99 వరకు యాదృచ్ఛికంగా మరియు సమానంగా పంపిణీ చేయబడతాయి. అందువల్ల, మనకు అవసరమైన పరిధిలోకి వచ్చే వాటిని మాత్రమే మేము దాటవేస్తాము.
ఉదాహరణకు, cacheDataBlockPercent = 20 సెట్ చేయండి మరియు ఏమి జరుగుతుందో చూడండి:
ఫలితం స్పష్టంగా ఉంది. దిగువ గ్రాఫ్‌లలో, అటువంటి త్వరణం ఎందుకు సంభవించిందో స్పష్టంగా తెలుస్తుంది - మేము డేటాను కాష్‌లో ఉంచే సిసిఫియన్ పనిని చేయకుండా చాలా GC వనరులను వెంటనే మార్టిన్ కుక్కల కాలువలోకి విసిరివేస్తాము:
అదే సమయంలో, CPU వినియోగం పెరుగుతుంది, కానీ ఉత్పాదకత కంటే చాలా తక్కువగా ఉంటుంది:
బ్లాక్‌కాష్‌లో నిల్వ చేయబడిన బ్లాక్‌లు భిన్నంగా ఉన్నాయని కూడా గమనించాలి. చాలా వరకు, దాదాపు 95%, డేటా కూడా. మరియు మిగిలినవి బ్లూమ్ ఫిల్టర్‌లు లేదా LEAF_INDEX మరియు వంటి మెటాడేటా . ఈ డేటా సరిపోదు, కానీ ఇది చాలా ఉపయోగకరంగా ఉంటుంది, ఎందుకంటే డేటాను నేరుగా యాక్సెస్ చేయడానికి ముందు, HBase మెటాను ఆశ్రయించి, ఇక్కడ మరింత శోధించడం అవసరమా అని అర్థం చేసుకోవడానికి మరియు అలా అయితే, ఆసక్తి ఉన్న బ్లాక్ ఎక్కడ ఉందో అర్థం చేసుకోవచ్చు.
అందువల్ల, కోడ్‌లో మనం చెక్ కండిషన్‌ను చూస్తాము buf.getBlockType().isData() మరియు ఈ మెటాకు ధన్యవాదాలు, మేము దానిని ఏ సందర్భంలోనైనా కాష్‌లో వదిలివేస్తాము.
ఇప్పుడు లోడ్‌ని పెంచి, లక్షణాన్ని ఒకేసారి బిగించండి. మొదటి పరీక్షలో మేము కటాఫ్ శాతం = 20 చేసాము మరియు BlockCache కొద్దిగా తక్కువగా ఉపయోగించబడింది. ఇప్పుడు దాన్ని 23%కి సెట్ చేద్దాం మరియు ఏ సమయంలో సంతృప్తత సంభవిస్తుందో చూడటానికి ప్రతి 100 నిమిషాలకు 5 థ్రెడ్‌లను జోడించండి:
ఇక్కడ మేము అసలు వెర్షన్ దాదాపు సెకనుకు సుమారు 100 వేల అభ్యర్థనల వద్ద పైకప్పును తాకినట్లు చూస్తాము. అయితే ప్యాచ్ 300 వేల వరకు త్వరణాన్ని ఇస్తుంది. అదే సమయంలో, మరింత త్వరణం ఇకపై అంత “ఉచితం” కాదని స్పష్టమవుతుంది; CPU వినియోగం కూడా పెరుగుతోంది.
అయితే, ఇది చాలా సొగసైన పరిష్కారం కాదు, ఎందుకంటే బ్లాక్‌ల శాతాన్ని కాష్ చేయాల్సిన అవసరం మాకు ముందుగానే తెలియదు, ఇది లోడ్ ప్రొఫైల్‌పై ఆధారపడి ఉంటుంది. అందువల్ల, రీడింగ్ ఆపరేషన్ల కార్యాచరణపై ఆధారపడి ఈ పరామితిని స్వయంచాలకంగా సర్దుబాటు చేయడానికి ఒక యంత్రాంగం అమలు చేయబడింది.
దీన్ని నియంత్రించడానికి మూడు ఎంపికలు జోడించబడ్డాయి:
hbase.lru.cache.heavy.eviction.count.limit — మనం ఆప్టిమైజేషన్ (అంటే స్కిప్పింగ్ బ్లాక్‌లు) ఉపయోగించడం ప్రారంభించడానికి ముందు కాష్ నుండి డేటాను తొలగించే ప్రక్రియ ఎన్నిసార్లు అమలు చేయబడాలో సెట్ చేస్తుంది. డిఫాల్ట్‌గా ఇది MAX_INT = 2147483647కి సమానం మరియు వాస్తవానికి ఫీచర్ ఈ విలువతో పని చేయడం ప్రారంభించదు. ఎందుకంటే తొలగింపు ప్రక్రియ ప్రతి 5 - 10 సెకన్లకు ప్రారంభమవుతుంది (ఇది లోడ్‌పై ఆధారపడి ఉంటుంది) మరియు 2147483647 * 10 / 60 / 60 / 24 / 365 = 680 సంవత్సరాలకు. అయితే, మేము ఈ పరామితిని 0కి సెట్ చేయవచ్చు మరియు లాంచ్ అయిన వెంటనే ఫీచర్ పని చేసేలా చేయవచ్చు.
అయితే, ఈ పరామితిలో పేలోడ్ కూడా ఉంది. మన లోడ్ స్వల్పకాలిక రీడ్‌లు (పగటిపూట చెప్పండి) మరియు దీర్ఘకాలిక రీడ్‌లు (రాత్రి సమయంలో) నిరంతరం విడదీయబడి ఉంటే, దీర్ఘ రీడ్ ఆపరేషన్‌లు జరుగుతున్నప్పుడు మాత్రమే ఫీచర్ ఆన్ చేయబడిందని మేము నిర్ధారించుకోవచ్చు.
ఉదాహరణకు, స్వల్పకాలిక రీడింగ్‌లు సాధారణంగా 1 నిమిషం వరకు ఉంటాయని మాకు తెలుసు. బ్లాక్‌లను విసిరేయడం ప్రారంభించాల్సిన అవసరం లేదు, కాష్‌కు కాలం చెల్లిన సమయం ఉండదు మరియు మేము ఈ పారామీటర్‌కు సమానంగా సెట్ చేయవచ్చు, ఉదాహరణకు, 10. ఇది ఆప్టిమైజేషన్ దీర్ఘకాలం మాత్రమే పనిచేయడం ప్రారంభిస్తుంది అనే వాస్తవానికి దారి తీస్తుంది- పదం క్రియాశీల పఠనం ప్రారంభమైంది, అనగా. 100 సెకన్లలో. అందువల్ల, మనకు స్వల్పకాలిక రీడ్ ఉంటే, అన్ని బ్లాక్‌లు కాష్‌లోకి వెళ్లి అందుబాటులో ఉంటాయి (ప్రామాణిక అల్గోరిథం ద్వారా తొలగించబడేవి తప్ప). మరియు మేము దీర్ఘకాలిక రీడ్‌లను చేసినప్పుడు, ఫీచర్ ఆన్ చేయబడుతుంది మరియు మేము చాలా ఎక్కువ పనితీరును కలిగి ఉంటాము.
hbase.lru.cache.heavy.eviction.mb.size.limit - 10 సెకన్లలో మనం కాష్‌లో ఎన్ని మెగాబైట్‌లను ఉంచాలనుకుంటున్నామో (మరియు, వాస్తవానికి, ఎవిక్ట్) సెట్ చేస్తుంది. ఫీచర్ ఈ విలువను చేరుకోవడానికి మరియు దానిని నిర్వహించడానికి ప్రయత్నిస్తుంది. పాయింట్ ఇది: మనం గిగాబైట్‌లను కాష్‌లోకి నెట్టివేస్తే, మనం గిగాబైట్‌లను తొలగించాల్సి ఉంటుంది మరియు ఇది మనం పైన చూసినట్లుగా చాలా ఖరీదైనది. అయినప్పటికీ, మీరు దీన్ని చాలా చిన్నదిగా సెట్ చేయడానికి ప్రయత్నించకూడదు, ఇది బ్లాక్ స్కిప్ మోడ్ ముందుగానే నిష్క్రమించేలా చేస్తుంది. శక్తివంతమైన సర్వర్‌ల కోసం (సుమారు 20-40 ఫిజికల్ కోర్లు), సుమారు 300-400 MB సెట్ చేయడం సరైనది. మధ్యతరగతి కోసం (~10 కోర్లు) 200-300 MB. బలహీనమైన సిస్టమ్‌లకు (2-5 కోర్లు) 50-100 MB సాధారణం కావచ్చు (వీటిపై పరీక్షించబడలేదు).
ఇది ఎలా పని చేస్తుందో చూద్దాం: మేము hbase.lru.cache.heavy.eviction.mb.size.limit = 500ని సెట్ చేసాము అనుకుందాం, కొంత రకమైన లోడ్ (పఠనం) ఉంది మరియు ప్రతి ~10 సెకన్లకు ఎన్ని బైట్లు ఉన్నాయో లెక్కిస్తాము. ఫార్ములా ఉపయోగించి తొలగించబడింది:
ఓవర్ హెడ్ = ఫ్రీడ్ బైట్స్ సమ్ (MB) * 100 / లిమిట్ (MB) - 100;
వాస్తవానికి 2000 MB తొలగించబడితే, ఓవర్‌హెడ్ దీనికి సమానం:
2000 * 100 / 500 - 100 = 300%
అల్గారిథమ్‌లు కొన్ని పదుల శాతం కంటే ఎక్కువ ఉండకుండా ఉండటానికి ప్రయత్నిస్తాయి, కాబట్టి ఫీచర్ కాష్ చేసిన బ్లాక్‌ల శాతాన్ని తగ్గిస్తుంది, తద్వారా ఆటో-ట్యూనింగ్ మెకానిజంను అమలు చేస్తుంది.
అయినప్పటికీ, లోడ్ తగ్గితే, కేవలం 200 MB మాత్రమే తొలగించబడి, ఓవర్‌హెడ్ ప్రతికూలంగా మారిందని అనుకుందాం (ఓవర్‌షూటింగ్ అని పిలవబడేది):
200 * 100 / 500 - 100 = -60%
దీనికి విరుద్ధంగా, ఓవర్‌హెడ్ సానుకూలంగా మారే వరకు ఫీచర్ కాష్ చేసిన బ్లాక్‌ల శాతాన్ని పెంచుతుంది.
ఇది నిజమైన డేటాపై ఎలా కనిపిస్తుందో అనేదానికి దిగువ ఉదాహరణ. 0% చేరుకోవడానికి ప్రయత్నించాల్సిన అవసరం లేదు, అది అసాధ్యం. ఇది దాదాపు 30 - 100% ఉన్నప్పుడు చాలా మంచిది, ఇది స్వల్పకాలిక సర్జ్‌ల సమయంలో ఆప్టిమైజేషన్ మోడ్ నుండి అకాల నిష్క్రమణను నివారించడానికి సహాయపడుతుంది.
hbase.lru.cache.heavy.eviction.overhead.coficiency — మనం ఎంత త్వరగా ఫలితాన్ని పొందాలనుకుంటున్నామో సెట్ చేస్తుంది. మా రీడ్‌లు చాలా పొడవుగా ఉన్నాయని మరియు వేచి ఉండకూడదని మాకు ఖచ్చితంగా తెలిస్తే, మేము ఈ నిష్పత్తిని పెంచవచ్చు మరియు అధిక పనితీరును వేగంగా పొందవచ్చు.
ఉదాహరణకు, మేము ఈ గుణకం = 0.01 సెట్ చేసాము. దీనర్థం ఓవర్‌హెడ్ (పైన చూడండి) ఫలిత ఫలితం ద్వారా ఈ సంఖ్యతో గుణించబడుతుంది మరియు కాష్ చేయబడిన బ్లాక్‌ల శాతం తగ్గించబడుతుంది. ఓవర్‌హెడ్ = 300% మరియు కోఎఫీషియంట్ = 0.01 అని అనుకుందాం, అప్పుడు కాష్ చేసిన బ్లాక్‌ల శాతం 3% తగ్గుతుంది.
ప్రతికూల ఓవర్‌హెడ్ (ఓవర్‌షూటింగ్) విలువలకు కూడా ఇదే విధమైన "బ్యాక్‌ప్రెషర్" లాజిక్ అమలు చేయబడుతుంది. రీడ్‌లు మరియు తొలగింపుల వాల్యూమ్‌లో స్వల్పకాలిక హెచ్చుతగ్గులు ఎల్లప్పుడూ సాధ్యమే కాబట్టి, ఆప్టిమైజేషన్ మోడ్ నుండి అకాల నిష్క్రమణను నివారించడానికి ఈ విధానం మిమ్మల్ని అనుమతిస్తుంది. బ్యాక్‌ప్రెషర్ విలోమ తర్కాన్ని కలిగి ఉంటుంది: ఓవర్‌షూటింగ్ ఎంత బలంగా ఉంటే, ఎక్కువ బ్లాక్‌లు కాష్ చేయబడతాయి.
అమలు కోడ్
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;
}
అసలు ఉదాహరణను ఉపయోగించి వీటన్నింటిని ఇప్పుడు చూద్దాం. మాకు ఈ క్రింది పరీక్ష స్క్రిప్ట్ ఉంది:
- స్కాన్ చేయడం ప్రారంభిద్దాం (25 థ్రెడ్‌లు, బ్యాచ్ = 100)
- 5 నిమిషాల తర్వాత, బహుళ-గెట్‌లను జోడించండి (25 థ్రెడ్‌లు, బ్యాచ్ = 100)
- 5 నిమిషాల తర్వాత, బహుళ-గెట్‌లను ఆఫ్ చేయండి (మళ్లీ స్కాన్ మాత్రమే మిగిలి ఉంది)
మేము రెండు పరుగులు చేస్తాము, ముందుగా hbase.lru.cache.heavy.eviction.count.limit = 10000 (ఇది వాస్తవానికి లక్షణాన్ని నిలిపివేస్తుంది), ఆపై పరిమితిని = 0 సెట్ చేయండి (దీనిని ప్రారంభిస్తుంది).
దిగువ లాగ్‌లలో ఫీచర్ ఎలా ఆన్ చేయబడిందో మరియు ఓవర్‌షూటింగ్‌ను 14-71%కి రీసెట్ చేయడం ఎలాగో చూస్తాము. కాలానుగుణంగా లోడ్ తగ్గుతుంది, ఇది బ్యాక్‌ప్రెషర్‌ని ఆన్ చేస్తుంది మరియు HBase మళ్లీ మరిన్ని బ్లాక్‌లను కాష్ చేస్తుంది.
RegionServer లాగ్ చేయండి
తొలగించబడినవి (MB): 0, నిష్పత్తి 0.0, ఓవర్‌హెడ్ (%): -100, భారీ ఎవిక్షన్ కౌంటర్: 0, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 100
తొలగించబడినవి (MB): 0, నిష్పత్తి 0.0, ఓవర్‌హెడ్ (%): -100, భారీ ఎవిక్షన్ కౌంటర్: 0, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 100
తొలగించబడినది (MB): 2170, నిష్పత్తి 1.09, ఓవర్‌హెడ్ (%): 985, భారీ తొలగింపు కౌంటర్: 1, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 91 <ప్రారంభం
తొలగించబడినవి (MB): 3763, నిష్పత్తి 1.08, ఓవర్‌హెడ్ (%): 1781, భారీ తొలగింపు కౌంటర్: 2, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 76
తొలగించబడినవి (MB): 3306, నిష్పత్తి 1.07, ఓవర్‌హెడ్ (%): 1553, భారీ తొలగింపు కౌంటర్: 3, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 61
తొలగించబడినవి (MB): 2508, నిష్పత్తి 1.06, ఓవర్‌హెడ్ (%): 1154, భారీ తొలగింపు కౌంటర్: 4, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 50
తొలగించబడినవి (MB): 1824, నిష్పత్తి 1.04, ఓవర్‌హెడ్ (%): 812, భారీ తొలగింపు కౌంటర్: 5, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 42
తొలగించబడినవి (MB): 1482, నిష్పత్తి 1.03, ఓవర్‌హెడ్ (%): 641, భారీ తొలగింపు కౌంటర్: 6, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 36
తొలగించబడినవి (MB): 1140, నిష్పత్తి 1.01, ఓవర్‌హెడ్ (%): 470, భారీ తొలగింపు కౌంటర్: 7, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 32
తొలగించబడినవి (MB): 913, నిష్పత్తి 1.0, ఓవర్‌హెడ్ (%): 356, భారీ తొలగింపు కౌంటర్: 8, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 29
తొలగించబడినవి (MB): 912, నిష్పత్తి 0.89, ఓవర్‌హెడ్ (%): 356, భారీ తొలగింపు కౌంటర్: 9, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 26
తొలగించబడినవి (MB): 684, నిష్పత్తి 0.76, ఓవర్‌హెడ్ (%): 242, భారీ తొలగింపు కౌంటర్: 10, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 24
తొలగించబడినవి (MB): 684, నిష్పత్తి 0.61, ఓవర్‌హెడ్ (%): 242, భారీ తొలగింపు కౌంటర్: 11, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 456, నిష్పత్తి 0.51, ఓవర్‌హెడ్ (%): 128, భారీ తొలగింపు కౌంటర్: 12, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 21
తొలగించబడినవి (MB): 456, నిష్పత్తి 0.42, ఓవర్‌హెడ్ (%): 128, భారీ తొలగింపు కౌంటర్: 13, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 20
తొలగించబడినవి (MB): 456, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 128, భారీ తొలగింపు కౌంటర్: 14, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 15, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.32, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 16, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.31, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 17, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.3, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 18, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.29, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 19, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.27, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 20, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.25, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 21, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.24, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 22, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.22, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 23, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.21, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 24, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.2, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 25, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.17, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 26, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 456, నిష్పత్తి 0.17, ఓవర్‌హెడ్ (%): 128, భారీ తొలగింపు కౌంటర్: 27, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18 < జోడించిన గెట్స్ (కానీ అదే పట్టిక)
తొలగించబడినవి (MB): 456, నిష్పత్తి 0.15, ఓవర్‌హెడ్ (%): 128, భారీ తొలగింపు కౌంటర్: 28, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.13, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 29, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.11, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 30, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.09, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 31, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.08, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 32, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.07, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 33, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.06, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 34, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.05, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 35, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.05, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 36, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.04, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 37, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినది (MB): 109, నిష్పత్తి 0.04, ఓవర్‌హెడ్ (%): -46, భారీ ఎవిక్షన్ కౌంటర్: 37, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22 < వెనుక ఒత్తిడి
తొలగించబడినవి (MB): 798, నిష్పత్తి 0.24, ఓవర్‌హెడ్ (%): 299, భారీ తొలగింపు కౌంటర్: 38, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 20
తొలగించబడినవి (MB): 798, నిష్పత్తి 0.29, ఓవర్‌హెడ్ (%): 299, భారీ తొలగింపు కౌంటర్: 39, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18
తొలగించబడినవి (MB): 570, నిష్పత్తి 0.27, ఓవర్‌హెడ్ (%): 185, భారీ తొలగింపు కౌంటర్: 40, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 17
తొలగించబడినవి (MB): 456, నిష్పత్తి 0.22, ఓవర్‌హెడ్ (%): 128, భారీ తొలగింపు కౌంటర్: 41, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 16
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.16, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 42, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 16
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.11, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 43, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 16
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.09, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 44, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 16
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.07, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 45, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 16
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.05, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 46, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 16
తొలగించబడినవి (MB): 222, నిష్పత్తి 0.04, ఓవర్‌హెడ్ (%): 11, భారీ తొలగింపు కౌంటర్: 47, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 16
తొలగించబడినది (MB): 104, నిష్పత్తి 0.03, ఓవర్‌హెడ్ (%): -48, భారీ తొలగింపు కౌంటర్: 47, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 21 < అంతరాయాన్ని పొందుతుంది
తొలగించబడినవి (MB): 684, నిష్పత్తి 0.2, ఓవర్‌హెడ్ (%): 242, భారీ తొలగింపు కౌంటర్: 48, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 19
తొలగించబడినవి (MB): 570, నిష్పత్తి 0.23, ఓవర్‌హెడ్ (%): 185, భారీ తొలగింపు కౌంటర్: 49, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.22, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 50, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.21, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 51, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.2, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 52, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.18, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 53, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.16, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 54, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18
తొలగించబడినవి (MB): 228, నిష్పత్తి 0.14, ఓవర్‌హెడ్ (%): 14, భారీ తొలగింపు కౌంటర్: 55, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 18
తొలగించబడినది (MB): 112, నిష్పత్తి 0.14, ఓవర్‌హెడ్ (%): -44, భారీ ఎవిక్షన్ కౌంటర్: 55, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 23 < వెనుక ఒత్తిడి
తొలగించబడినవి (MB): 456, నిష్పత్తి 0.26, ఓవర్‌హెడ్ (%): 128, భారీ తొలగింపు కౌంటర్: 56, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.31, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 57, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 58, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 59, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 60, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 61, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 62, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 63, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.32, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 64, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 65, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 66, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.32, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 67, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 68, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.32, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 69, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.32, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 70, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 71, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 72, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 73, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 74, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 75, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 342, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): 71, భారీ తొలగింపు కౌంటర్: 76, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 22
తొలగించబడినవి (MB): 21, నిష్పత్తి 0.33, ఓవర్‌హెడ్ (%): -90, భారీ ఎవిక్షన్ కౌంటర్: 76, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 32
తొలగించబడినవి (MB): 0, నిష్పత్తి 0.0, ఓవర్‌హెడ్ (%): -100, భారీ ఎవిక్షన్ కౌంటర్: 0, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 100
తొలగించబడినవి (MB): 0, నిష్పత్తి 0.0, ఓవర్‌హెడ్ (%): -100, భారీ ఎవిక్షన్ కౌంటర్: 0, ప్రస్తుత కాషింగ్ డేటాబ్లాక్ (%): 100
ఒకే ప్రక్రియను రెండు కాష్ విభాగాల మధ్య సంబంధాన్ని గ్రాఫ్ రూపంలో చూపించడానికి స్కాన్‌లు అవసరమవుతాయి - సింగిల్ (ఇంతకుముందు ఎన్నడూ అభ్యర్థించని బ్లాక్‌లు) మరియు బహుళ (కనీసం ఒక్కసారైనా “అభ్యర్థించిన” డేటా ఇక్కడ నిల్వ చేయబడుతుంది):
చివరకు, పారామితుల ఆపరేషన్ గ్రాఫ్ రూపంలో ఎలా ఉంటుంది. పోలిక కోసం, కాష్ ప్రారంభంలో పూర్తిగా ఆపివేయబడింది, ఆపై HBase కాషింగ్‌తో ప్రారంభించబడింది మరియు ఆప్టిమైజేషన్ పనిని 5 నిమిషాలు (30 ఎవిక్షన్ సైకిల్స్) ఆలస్యం చేస్తుంది.
పుల్ రిక్వెస్ట్‌లో పూర్తి కోడ్‌ను కనుగొనవచ్చు గితుబ్‌లో.
అయితే, ఈ పరిస్థితుల్లో ఈ హార్డ్‌వేర్‌లో సెకనుకు 300 వేల రీడ్‌లు సాధించడం అంతా ఇంతా కాదు. వాస్తవం ఏమిటంటే, మీరు HDFS ద్వారా డేటాను యాక్సెస్ చేయవలసి వచ్చినప్పుడు, ShortCircuitCache (ఇకపై SSCగా సూచిస్తారు) మెకానిజం ఉపయోగించబడుతుంది, ఇది నెట్‌వర్క్ పరస్పర చర్యలను నివారించడం ద్వారా డేటాను నేరుగా యాక్సెస్ చేయడానికి మిమ్మల్ని అనుమతిస్తుంది.
ప్రొఫైలింగ్ ఈ మెకానిజం పెద్ద లాభాలను ఇచ్చినప్పటికీ, ఏదో ఒక సమయంలో అడ్డంకిగా మారుతుంది, ఎందుకంటే దాదాపు అన్ని భారీ కార్యకలాపాలు లాక్ లోపల జరుగుతాయి, ఇది ఎక్కువ సమయం నిరోధించడానికి దారితీస్తుంది.
దీన్ని గ్రహించిన తర్వాత, స్వతంత్ర SSCల శ్రేణిని సృష్టించడం ద్వారా సమస్యను అధిగమించవచ్చని మేము గ్రహించాము:
private final ShortCircuitCache[] shortCircuitCache;
...
shortCircuitCache = new ShortCircuitCache[this.clientShortCircuitNum];
for (int i = 0; i < this.clientShortCircuitNum; i++)
this.shortCircuitCache[i] = new ShortCircuitCache(…);
ఆపై చివరి ఆఫ్‌సెట్ అంకె వద్ద కూడళ్లను మినహాయించి, వారితో పని చేయండి:
public ShortCircuitCache getShortCircuitCache(long idx) {
return shortCircuitCache[(int) (idx % clientShortCircuitNum)];
}
ఇప్పుడు మీరు పరీక్షను ప్రారంభించవచ్చు. దీన్ని చేయడానికి, మేము HDFS నుండి ఫైల్‌లను సాధారణ బహుళ-థ్రెడ్ అప్లికేషన్‌తో చదువుతాము. పారామితులను సెట్ చేయండి:
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
మరియు కేవలం ఫైళ్లను చదవండి:
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);
}
ఈ కోడ్ ప్రత్యేక థ్రెడ్‌లలో అమలు చేయబడుతుంది మరియు మేము ఏకకాలంలో చదివే ఫైల్‌ల సంఖ్యను (10 నుండి 200 వరకు - క్షితిజ సమాంతర అక్షం) మరియు కాష్‌ల సంఖ్యను (1 నుండి 10 వరకు - గ్రాఫిక్స్) పెంచుతాము. నిలువు అక్షం ఒక కాష్ మాత్రమే ఉన్నప్పుడు కేసుకు సంబంధించి SSC పెరుగుదల ఫలితంగా ఏర్పడే త్వరణాన్ని చూపుతుంది.
గ్రాఫ్‌ను ఎలా చదవాలి: ఒక కాష్‌తో 100 KB బ్లాక్‌లలో 64 వేల రీడ్‌ల అమలు సమయం 78 సెకన్లు అవసరం. అయితే 5 కాష్‌లతో ఇది 16 సెకన్లు పడుతుంది. ఆ. ~5 రెట్లు త్వరణం ఉంది. గ్రాఫ్ నుండి చూడగలిగినట్లుగా, తక్కువ సంఖ్యలో సమాంతర రీడ్‌లకు ప్రభావం చాలా గుర్తించదగినది కాదు; 50 కంటే ఎక్కువ థ్రెడ్ రీడ్‌లు ఉన్నప్పుడు ఇది గుర్తించదగిన పాత్రను పోషిస్తుంది. SSCల సంఖ్యను 6 నుండి పెంచడం కూడా గమనించదగినది. మరియు పైన గణనీయంగా చిన్న పనితీరు పెరుగుదలను ఇస్తుంది.
గమనిక 1: పరీక్ష ఫలితాలు చాలా అస్థిరంగా ఉన్నందున (క్రింద చూడండి), 3 పరుగులు నిర్వహించబడ్డాయి మరియు ఫలిత విలువలు సగటున నిర్ణయించబడ్డాయి.
గమనిక 2: యాదృచ్ఛిక యాక్సెస్‌ను కాన్ఫిగర్ చేయడం ద్వారా పనితీరు లాభం ఒకేలా ఉంటుంది, అయినప్పటికీ యాక్సెస్ కొంచెం నెమ్మదిగా ఉంటుంది.
అయినప్పటికీ, HBase విషయంలో కాకుండా, ఈ త్వరణం ఎల్లప్పుడూ ఉచితం కాదని స్పష్టం చేయడం అవసరం. ఇక్కడ మేము లాక్‌లపై వేలాడదీయడానికి బదులుగా, ఎక్కువ పని చేసే CPU సామర్థ్యాన్ని “అన్‌లాక్” చేస్తాము.
ఇక్కడ మీరు సాధారణంగా, కాష్‌ల సంఖ్య పెరుగుదల CPU వినియోగంలో సుమారుగా దామాషా పెరుగుదలను ఇస్తుందని గమనించవచ్చు. అయితే, కొంచెం ఎక్కువ విజేత కలయికలు ఉన్నాయి.
ఉదాహరణకు, SSC = 3 సెట్టింగ్‌ని నిశితంగా పరిశీలిద్దాం. పరిధిలో పనితీరులో పెరుగుదల దాదాపు 3.3 రెట్లు ఉంటుంది. మూడు వేర్వేరు పరుగుల ఫలితాలు క్రింద ఉన్నాయి.
CPU వినియోగం సుమారు 2.8 రెట్లు పెరుగుతుంది. తేడా చాలా పెద్దది కాదు, కానీ చిన్న గ్రేటా ఇప్పటికే సంతోషంగా ఉంది మరియు పాఠశాలకు హాజరు కావడానికి మరియు పాఠాలు తీసుకోవడానికి సమయం ఉండవచ్చు.
అందువల్ల, HDFSకి బల్క్ యాక్సెస్‌ను ఉపయోగించే ఏదైనా సాధనం కోసం ఇది సానుకూల ప్రభావాన్ని చూపుతుంది (ఉదాహరణకు స్పార్క్, మొదలైనవి), అప్లికేషన్ కోడ్ తేలికైనది (అంటే ప్లగ్ HDFS క్లయింట్ వైపు ఉంది) మరియు ఉచిత CPU పవర్ ఉంటే . తనిఖీ చేయడానికి, HBase నుండి చదవడం కోసం BlockCache ఆప్టిమైజేషన్ మరియు SSC ట్యూనింగ్ యొక్క మిశ్రమ ఉపయోగం ఎలాంటి ప్రభావాన్ని చూపుతుందో పరీక్షిద్దాం.
అటువంటి పరిస్థితులలో శుద్ధి చేసిన పరీక్షలలో (ఏ ప్రాసెసింగ్ లేకుండా చదవడం) ప్రభావం అంత గొప్పది కాదని చూడవచ్చు, అయితే ఇక్కడ అదనంగా 80Kని పిండడం చాలా సాధ్యమే. మొత్తంగా, రెండు ఆప్టిమైజేషన్‌లు గరిష్టంగా 4x వేగాన్ని అందిస్తాయి.
ఈ ఆప్టిమైజేషన్ కోసం PR కూడా చేయబడింది , ఇది విలీనం చేయబడింది మరియు ఈ కార్యాచరణ భవిష్యత్ విడుదలలలో అందుబాటులో ఉంటుంది.
చివరగా, ఇలాంటి వైడ్-కాలమ్ డేటాబేస్, కాసాండ్రా మరియు హెచ్‌బేస్ యొక్క పఠన పనితీరును పోల్చడం ఆసక్తికరంగా ఉంది.
దీన్ని చేయడానికి, మేము రెండు హోస్ట్‌ల (మొత్తం 800 థ్రెడ్‌లు) నుండి ప్రామాణిక YCSB లోడ్ టెస్టింగ్ యుటిలిటీని ప్రారంభించాము. సర్వర్ వైపు - 4 హోస్ట్‌లలో RegionServer మరియు Cassandra యొక్క 4 ఉదంతాలు (క్లయింట్‌లు తమ ప్రభావాన్ని నివారించడానికి నడుస్తున్న వాటిని కాదు). రీడింగ్‌లు పరిమాణం యొక్క పట్టికల నుండి వచ్చాయి:
HBase – HDFSలో 300 GB (100 GB స్వచ్ఛమైన డేటా)
కాసాండ్రా - 250 GB (రెప్లికేషన్ ఫ్యాక్టర్ = 3)
ఆ. వాల్యూమ్ ఇంచుమించు అదే విధంగా ఉంది (HBaseలో కొంచెం ఎక్కువ).
HBase పారామితులు:
dfs.client.short.circuit.num = 5 (HDFS క్లయింట్ ఆప్టిమైజేషన్)
hbase.lru.cache.heavy.eviction.count.limit = 30 - అంటే 30 తొలగింపుల తర్వాత (~5 నిమిషాలు) ప్యాచ్ పని చేయడం ప్రారంభిస్తుంది
hbase.lru.cache.heavy.eviction.mb.size.limit = 300 - కాషింగ్ మరియు ఎవిక్షన్ యొక్క లక్ష్య పరిమాణం
YCSB లాగ్‌లు అన్వయించబడ్డాయి మరియు Excel గ్రాఫ్‌లలోకి సంకలనం చేయబడ్డాయి:
మీరు చూడగలిగినట్లుగా, ఈ ఆప్టిమైజేషన్‌లు ఈ పరిస్థితులలో ఈ డేటాబేస్‌ల పనితీరును సరిపోల్చడం మరియు సెకనుకు 450 వేల రీడ్‌లను సాధించడం సాధ్యం చేస్తాయి.
ఉత్పాదకత కోసం అద్భుతమైన పోరాటంలో ఈ సమాచారం ఎవరికైనా ఉపయోగకరంగా ఉంటుందని మేము ఆశిస్తున్నాము.
మూలం: www.habr.com