የንባብ ፍጥነት ከHBase እስከ 3 ጊዜ እና ከኤችዲኤፍኤስ እስከ 5 ጊዜ እንዴት እንደሚጨምር

ከትልቅ ዳታ ጋር ሲሰሩ ከፍተኛ አፈፃፀም ከሚያስፈልጉት ቁልፍ መስፈርቶች አንዱ ነው. እኛ፣ በ Sberbank የውሂብ ጭነት አስተዳደር ውስጥ፣ ሁሉንም ማለት ይቻላል ግብይቶችን ወደ ሃዱፕ-ተኮር ዳታ ክላውድ እያስገባን ነው፣ እና ስለዚህ ትልቅ የመረጃ ፍሰቶችን እያስተናገድን ነው። በተፈጥሮ እኛ ሁል ጊዜ አፈፃፀሙን ለማሻሻል መንገዶችን እንፈልጋለን ፣ እና አሁን የRegionalServer HBase እና HDFS ደንበኛን እንዴት ማስተካከል እንደቻልን ልንነግርዎ እንፈልጋለን ፣ ይህም የንባብ ኦፕሬሽኑን ፍጥነት በከፍተኛ ሁኔታ ለማሳደግ አስችሎታል።


ሆኖም ወደ ማሻሻያዎቹ ይዘት ከመቀጠልዎ በፊት በመርህ ደረጃ በኤችዲዲ ላይ ከተቀመጡ ሊታለፉ የማይችሉትን ገደቦች ማውራት ጠቃሚ ነው ።

ለምን HDD እና ፈጣን የዘፈቀደ መዳረሻ ንባብ የማይጣጣሙ ናቸው።
እንደሚታወቀው HBase እና ሌሎች ብዙ የውሂብ ጎታዎች መረጃን በበርካታ አስር ኪሎባይት መጠናቸው ያከማቻሉ። በነባሪ ይህ ወደ 64 ኪ.ባ. አሁን 100 ባይት ብቻ ማግኘት እንዳለብን አስቡት እና HBase ይህን መረጃ የተወሰነ ቁልፍ በመጠቀም እንዲሰጠን እንጠይቃለን። በHFiles ውስጥ ያለው የማገጃ መጠን 64 ኪባ ስለሆነ፣ ጥያቄው ከሚያስፈልገው 640 እጥፍ ይበልጣል (አንድ ደቂቃ ብቻ!)።

በተጨማሪም፣ ጥያቄው በኤችዲኤፍኤስ እና በሜታዳታ መሸጎጫ ዘዴው በኩል ስለሚያልፍ ShortCircuitCache (ይህም በቀጥታ ወደ ፋይሎች መድረስን ይፈቅዳል), ከዚያ ይህ ቀድሞውኑ 1 ሜባ ከዲስክ ማንበብን ያመጣል. ሆኖም, ይህ በመለኪያው ሊስተካከል ይችላል dfs.client.read.shortcircuit.buffer.መጠን እና በብዙ አጋጣሚዎች ይህንን ዋጋ መቀነስ ምክንያታዊ ነው, ለምሳሌ ወደ 126 ኪ.ባ.

ይህን እናደርጋለን እንበል ነገር ግን በተጨማሪ መረጃን በጃቫ api ማንበብ ስንጀምር እንደ FileChannel.read ባሉ ተግባራት እና ኦፕሬቲንግ ሲስተሙን የተወሰነውን የውሂብ መጠን እንዲያነብ በመጠየቅ "ልክ እንደ ሆነ" 2 እጥፍ ይቀንሳል. ፣ ማለትም እ.ኤ.አ. በእኛ ሁኔታ በ 256 ኪ.ቢ. ምክንያቱም ይህን ባህሪ ለመከላከል በጃቫ ውስጥ FADV_RANDOM ባንዲራ ለማዘጋጀት ቀላል መንገድ ስለሌለ ነው።

በውጤቱም, የእኛን 100 ባይት ለማግኘት, 2600 እጥፍ ተጨማሪ በኮድ ውስጥ ይቀንሳል. መፍትሄው ግልፅ የሆነ ይመስላል ፣የብሎክ መጠኑን ወደ ኪሎባይት እንቀንሰው ፣የተጠቀሰውን ባንዲራ እናስቀምጠው እና ታላቅ የእውቀት መፋጠን እናገኝ። ችግሩ ግን የማገጃውን መጠን በ 2 ጊዜ በመቀነስ በአንድ ክፍለ ጊዜ የተቀነሰ ባይት ቁጥርን በ 2 እጥፍ እንቀንሳለን.

የFADV_RANDOM ባንዲራ በማዘጋጀት የተወሰነ ትርፍ ማግኘት ይቻላል ነገር ግን በከፍተኛ ባለብዙ-ክር እና 128 ኪባ የማገጃ መጠን ብቻ ነው፣ ነገር ግን ይህ ቢበዛ አስር በመቶዎች የሚቆጠሩ በመቶዎች የሚቆጠሩ ናቸው።

ፈተናዎቹ የተካሄዱት በ100 ፋይሎች ላይ ሲሆን እያንዳንዳቸው 1 ጂቢ መጠን ያላቸው እና በ10 HDDs ላይ ይገኛሉ።

በእንደዚህ ዓይነት ፍጥነት በመሠረቱ የምንቆጥረውን እናሰላለን-
ከ 10 ዲስኮች በ 280 ሜባ / ሰ ፍጥነት እናነባለን እንበል, ማለትም. 3 ሚሊዮን ጊዜ 100 ባይት። ግን እንደምናስታውሰው, ከተነበበው 2600 እጥፍ ያነሰ ውሂብ እንፈልጋለን. ስለዚህ, 3 ሚሊዮን ለ 2600 እናካፍላለን እና እናገኛለን በሰከንድ 1100 መዝገቦች.

ተስፋ አስቆራጭ፣ አይደል? ተፈጥሮ እንዲህ ነው። የዘፈቀደ መዳረሻ በኤችዲዲ ላይ የውሂብ መዳረሻ - ምንም እንኳን የማገጃው መጠን ምንም ይሁን ምን. ይህ የነሲብ ተደራሽነት አካላዊ ገደብ ነው፣ እና ምንም አይነት ዳታቤዝ በእንደዚህ አይነት ሁኔታዎች ተጨማሪ መጭመቅ አይችልም።

ታዲያ መሠረቶች በጣም ከፍተኛ ፍጥነትን እንዴት ማግኘት ይችላሉ? ለዚህ ጥያቄ መልስ ለማግኘት በሚከተለው ሥዕል ላይ ምን እንደ ሆነ እንመልከት።

እዚህ የመጀመሪያዎቹ ደቂቃዎች ፍጥነቱ በሴኮንድ አንድ ሺህ ያህል ሪከርዶች መሆኑን እናያለን. ሆኖም ፣ ከተጠየቀው በላይ ብዙ በመቀነሱ ምክንያት መረጃው በስርዓተ ክወናው (ሊኑክስ) ቡፍ / መሸጎጫ ውስጥ ተቀምጧል እና ፍጥነቱ በሰከንድ ወደ 60 ሺህ ጨዋነት ያድጋል።

ስለዚህ፣ በስርዓተ ክወናው መሸጎጫ ውስጥ ያሉትን ወይም በኤስኤስዲ/ኤንቪኤምኤ ማከማቻዎች ውስጥ በተነፃፃሪ የመዳረሻ ፍጥነት ውስጥ የሚገኙትን የእነዚያን መረጃዎች ብቻ ተደራሽነትን ማፋጠን እንሰራለን።

በእኛ ሁኔታ ፣ በ 4 አገልጋዮች ላይ ሙከራዎችን እናደርጋለን ፣ እያንዳንዳቸው እንደሚከተለው ይከፈላሉ ።

ሲፒዩ፡ Xeon E5-2680 v4 @ 2.40GHz 64 ክሮች።
ማህደረ ትውስታ: 730 ጊባ.
ጃቫ ስሪት: 1.8.0_111

እና እዚህ ዋናው ነጥብ ማንበብ የሚያስፈልገው በሰንጠረዦች ውስጥ ያለው የውሂብ መጠን ነው. እውነታው ግን ሙሉ በሙሉ ወደ HBase መሸጎጫ ውስጥ ከሚገባው ሠንጠረዥ ላይ መረጃን ካነበቡ ከኦፕሬቲንግ ሲስተሙ ቡፍ/መሸጎጫ ለማንበብ እንኳን አይመጣም። ምክንያቱም HBase በነባሪነት 40% ማህደረ ትውስታን BlockCache ለተባለ መዋቅር ይመድባል። በእውነቱ፣ ይህ ConcurrentHashMap ነው፣ ቁልፉ የፋይል ስም + የማገጃው ማካካሻ ሲሆን እሴቱ በዚህ ማካካሻ ላይ ያለው ትክክለኛው ዳታ ነው።

ስለዚህ, ከዚህ መዋቅር ብቻ ስናነብ, እኛ ታላቅ ፍጥነት ይመልከቱእንደ አንድ ሚሊዮን ጥያቄዎች በሰከንድ። ግን በመቶዎች የሚቆጠሩ ጊጋባይት ማህደረ ትውስታን ለዳታቤዝ ፍላጎቶች ብቻ መስጠት እንደማንችል እናስብ ፣ ምክንያቱም ብዙ ሌሎች ጠቃሚ ነገሮች በእነዚህ አገልጋዮች ላይ እየተሽከረከሩ ነው።

ለምሳሌ, በእኛ ሁኔታ, በአንድ RS ላይ ያለው የ BlockCache መጠን 12 ጂቢ ገደማ ነው. በአንድ መስቀለኛ መንገድ ላይ ሁለት RS አረፍን, ማለትም. 96 ጂቢ በሁሉም አንጓዎች ላይ ለ BlockCache ተመድቧል። እና በተመሳሳይ ጊዜ, ብዙ ተጨማሪ መረጃዎች አሉ, ለምሳሌ, እያንዳንዳቸው 4 ሰንጠረዦች, 130 ክልሎች, በ 800 ሜባ መጠን ያላቸው ፋይሎች, በ FAST_DIFF የተጨመቁ, ማለትም. በአጠቃላይ 410 ጂቢ (ይህ ንጹህ መረጃ ነው, ማለትም የማባዛትን ሁኔታ ግምት ውስጥ ሳያስገባ).

ስለዚህ, BlockCache ከጠቅላላው መረጃ 23% ብቻ ነው እና ይህ BigData ተብሎ ከሚጠራው ትክክለኛ ሁኔታ ጋር በጣም የቀረበ ነው. እና እዚህ በጣም ሳቢው ይጀምራል - ከሁሉም በኋላ ፣ ትንሽ መሸጎጫ ሲመታ ፣ አፈፃፀሙ እየባሰ መምጣቱ ግልፅ ነው። ደግሞም ፣ ሚስጥራዊነት በሚፈጠርበት ጊዜ ብዙ ስራዎችን መሥራት አለብዎት - ማለትም የስርዓት ተግባራትን ከመጥራት በፊት ውረድ. ነገር ግን, ይህ ማስቀረት አይቻልም, እና ስለዚህ ሙሉ ለሙሉ የተለየ ገፅታን እናስብ - በመሸጎጫው ውስጥ ያለው መረጃ ምን ይሆናል?

ሁኔታውን እናቅልለው እና 1 ነገር ብቻ የተቀመጠበት መሸጎጫ እንዳለን እናስብ። ከካሼው 3 እጥፍ በሚበልጥ የውሂብ መጠን ለመስራት ስንሞክር ምን እንደሚፈጠር የሚያሳይ ምሳሌ እዚህ አለ፡-

1. እገዳ 1 በመሸጎጫ ውስጥ ያስቀምጡ
2. እገዳ 1 ከመሸጎጫ ውስጥ ያስወግዱ
3. እገዳ 2 በመሸጎጫ ውስጥ ያስቀምጡ
4. እገዳ 2 ከመሸጎጫ ውስጥ ያስወግዱ
5. እገዳ 3 በመሸጎጫ ውስጥ ያስቀምጡ

5 ድርጊቶች ተከናውነዋል! ነገር ግን፣ ይህ ሁኔታ መደበኛ ተብሎ ሊጠራ አይችልም፣ በእርግጥ፣ HBase ሙሉ ለሙሉ የማይጠቅም ስራ እንዲሰራ እያስገደድነው ነው። አዲስ የመረጃ ክፍል ስለመጣ ወዲያውኑ ለመጣል ከስርዓተ ክወናው መሸጎጫ ላይ ያለማቋረጥ ውሂብ ያነባል፣ በብሎክካሼው ውስጥ ያስቀምጠዋል። በጽሁፉ መጀመሪያ ላይ ያለው አኒሜሽን የችግሩን ምንነት ያሳያል - ቆሻሻ ሰብሳቢው ከገበታዎቹ ውጪ ነው፣ ከባቢ አየር እየሞቀ ነው፣ ትንሿ ግሬታ በሩቅ እና በሞቃታማ ስዊድን ውስጥ እየተበሳጨች ነው። እና እኛ የአይቲ ሰዎች ህጻናት በሚያዝኑበት ጊዜ አንወደውም, ስለዚህ በዚህ ጉዳይ ላይ ምን ሊደረግ እንደሚችል ማሰብ እንጀምራለን.

ግን ሁሉም ብሎኮች በመሸጎጫው ውስጥ ካልተቀመጡ ፣ ግን የተወሰነ መቶኛ ብቻ ፣ መሸጎጫው ከመጠን በላይ እንዳይፈስስ? በ 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 አዘጋጅ እና ምን እንደተፈጠረ ተመልከት፡

ውጤቱ ግልጽ ነው. ከዚህ በታች ባሉት ግራፎች ውስጥ ይህ ማፋጠን ለምን እንደተከሰተ ግልፅ ይሆናል - ወዲያውኑ በማርስ ውሾች ላይ ወደ ፍሳሽ ማስወገጃው ለመጣል የሲሲፊን ጉልበት ሳናደርግ ብዙ የጂሲ ሀብቶችን እንቆጥባለን ።

በተመሳሳይ ጊዜ የሲፒዩ አጠቃቀም ያድጋል ነገር ግን ከአፈጻጸም በጣም ያነሰ ነው፡

እዚህ ላይ በብሎክካሼ ውስጥ የተከማቹ ብሎኮች የተለያዩ መሆናቸውን ልብ ሊባል የሚገባው ጉዳይ ነው። አብዛኛው፣ 95% ገደማ፣ ራሱ መረጃ ነው። እና ቀሪው እንደ Bloom filters ወይም LEAF_INDEX እና ያሉ ሜታዳታ ነው። ወዘተ.. ይህ ውሂብ በቂ አይደለም, ነገር ግን በጣም ጠቃሚ ነው, ምክንያቱም በቀጥታ ወደ ውሂቡ ከመዞርዎ በፊት, HBase ሜታውን በመመልከት እዚህ የበለጠ መፈለግ አስፈላጊ መሆኑን እና እንደዚያ ከሆነ, ለእሱ ፍላጎት ያለው እገዳ የት እንዳለ ለመረዳት.

ስለዚህ, በኮዱ ውስጥ የሁኔታ ማረጋገጫን እናያለን buf.getBlockType().isData() እና ለዚህ ሜታ ምስጋና ይግባውና በማንኛውም ሁኔታ መሸጎጫ ውስጥ እናስቀምጣለን።

አሁን ጭነቱን እንጨምር እና በተመሳሳይ ጊዜ ባህሪውን በትንሹ አስተካክል. በመጀመሪያው ፈተና የመቁረጫውን መቶኛ = 20 አድርገናል እና BlockCache ትንሽ ተጭኖ ነበር። አሁን ወደ 23% እናስቀምጠው እና ሙሌት ሲከሰት ለማየት በየ 100 ደቂቃው 5 ክሮች እንጨምር።

እዚህ ላይ የመጀመሪያው ስሪት በሰከንድ 100 ሺህ በሚጠጉ ጥያቄዎች ላይ ወዲያውኑ ጣሪያውን እንደሚመታ እናያለን። ፕላስተር እስከ 300 ሺህ ፍጥነትን ይሰጣል። በተመሳሳይ ጊዜ, ተጨማሪ ማፋጠን ከአሁን በኋላ "ነጻ" እንዳልሆነ ግልጽ ነው, የሲፒዩ አጠቃቀምም እያደገ ነው.

ሆኖም ፣ ይህ በጣም የሚያምር መፍትሄ አይደለም ፣ ምክንያቱም ምን ያህል የብሎኮች መቶኛ ወደ መሸጎጫ አስቀድመን አናውቅም ፣ በጭነት መገለጫው ላይ የተመሠረተ ነው። ስለዚህ በንባብ ስራዎች እንቅስቃሴ ላይ በመመስረት ይህንን ግቤት በራስ-ሰር ለማስተካከል ዘዴ ተተግብሯል።

ይህንን ለመቆጣጠር ሶስት አማራጮች ተጨምረዋል፡-

hbase.lru.cache.ከባድ.ማስወጣት.መቁጠር.ገደብ - ማመቻቸትን መጠቀም ከመጀመራችን በፊት መረጃን ከመሸጎጫው የማስወጣት ሂደት ምን ያህል ጊዜ መጀመር እንዳለበት ያዘጋጃል (ማለትም ብሎኮችን መዝለል)። በነባሪ፣ ከMAX_INT = 2147483647 ጋር እኩል ነው እና በእውነቱ ባህሪው ከዚህ እሴት ጋር መስራት አይጀምርም ማለት ነው። ምክንያቱም የማፈናቀሉ ሂደት በየ 5 - 10 ሴኮንድ (በጭነቱ ላይ የተመሰረተ ነው) እና 2147483647 * 10/60/60/24/365 = 680 ዓመታት። ነገር ግን፣ ይህንን ግቤት ወደ 0 እናዘጋጃለን እና ባህሪው ከጅምሩ በኋላ ወዲያውኑ እንዲሰራ ማድረግ እንችላለን።

ሆኖም፣ በዚህ ግቤት ውስጥ የመክፈያ ጭነትም አለ። የአጭር ጊዜ ንባብ (ቀን እንበል) እና የረዥም ጊዜ ንባብ (በሌሊት) ያለማቋረጥ የተጠላለፉ የጭነቱ ተፈጥሮ ካለን የረጅም ጊዜ የማንበብ ስራዎች ሲከናወኑ ብቻ ባህሪው እንዲበራ ማድረግ እንችላለን። በሂደት ላይ.

ለምሳሌ፣ የአጭር ጊዜ ንባብ አብዛኛውን ጊዜ 1 ደቂቃ ያህል እንደሚቆይ እናውቃለን። ብሎኮችን መወርወር መጀመር አያስፈልግም ፣ መሸጎጫው ጊዜው ያለፈበት ለመሆን ጊዜ አይኖረውም ፣ እና ከዚያ ይህንን ግቤት ለምሳሌ 10 ን ማዋቀር እንችላለን ፣ ይህ ማመቻቸት ረጅም ንቁ ንባብ ሲኖር ብቻ ወደመሆኑ እውነታ ይመራል ። ተጀምሯል፣ i. ከ 100 ሰከንድ በኋላ. ስለዚህ የአጭር ጊዜ ንባብ ካለን ሁሉም ብሎኮች ወደ መሸጎጫው ውስጥ ይገባሉ እና ይገኛሉ (በመደበኛ ስልተ ቀመር ከሚወጡት በስተቀር)። እና የረጅም ጊዜ ንባቦችን ስናደርግ ባህሪው ይበራል እና በጣም የተሻለ አፈጻጸም ይኖረናል።

hbase.lru.cache.ከባድ.ማስወጣት.mb.መጠን.ገደብ - በ10 ሰከንድ ውስጥ ምን ያህል ሜጋባይት መሸጎጫ ውስጥ ማስቀመጥ እንደምንፈልግ ያዘጋጃል። ባህሪው ይህንን እሴት ለመድረስ እና ለማቆየት ይሞክራል። ዋናው ነገር ጊጋባይት ወደ መሸጎጫው ውስጥ ካስገባን ጊጋባይት መባረር አለበት ይህ ደግሞ ከላይ እንዳየነው በጣም ውድ ነው። ነገር ግን, በጣም ትንሽ ለማዘጋጀት መሞከር የለብዎትም, ምክንያቱም ይህ ከብሎክ መዝለል ሁነታ ያለጊዜው መውጣትን ያመጣል. ለኃይለኛ አገልጋዮች (ከ20-40 አካላዊ ኮሮች) ከ300-400 ሜባ አካባቢ ማዘጋጀት ጥሩ ነው። ለመካከለኛው ክፍል (~ 10 ኮር) 200-300 ሜባ. ለደካማ ስርዓቶች (2-5 ኮር) 50-100 ሜባ መደበኛ ሊሆን ይችላል (በእንደዚህ አይነት ስርዓቶች ላይ አይሞከርም).

እንዴት እንደሚሰራ እንመልከት፡- hbase.lru.cache.heavy.eviction.mb.size.limit = 500 አዘጋጅተናል እንበል፣ አንድ ዓይነት ጭነት (ማንበብ) አለ ከዚያም በየ~10 ሰከንድ ምን ያህል ባይት እንደተባረረ እናሰላለን። በቀመር፡-

ከአቅም በላይ = የተለቀቀው ባይት ድምር (ሜባ) * 100 / ገደብ (ሜባ) - 100;

በእውነቱ 2000 ሜባ ከተባረሩ ፣ ከዚያ በላይ ያለው ክፍያ ከሚከተሉት ጋር እኩል ነው

2000 * 100/500 - 100 = 300%

አልጎሪዝም ከጥቂት አስር በመቶ ያልበለጠ ለመደገፍ ይሞክራል፣ስለዚህ ባህሪው የተሸጎጡ ብሎኮችን መቶኛ ይቀንሳል፣በዚህም የራስ-ማስተካከያ ዘዴን ተግባራዊ ያደርጋል።

ነገር ግን፣ ጭነቱ ከቀነሰ፣ 200 ሜጋ ባይት ብቻ ተባረረ እና ኦቨር ሄድ አሉታዊ ይሆናል (ከመጠን በላይ መተኮስ የሚባለው) እንበል፡-

200 * 100/500 - 100 = -60%

ያ ባህሪ፣ በተቃራኒው የተሸጎጡ ብሎኮች መቶኛን ይጨምራል Overhead አዎንታዊ እስኪሆን ድረስ።

ከታች በእውነተኛ ውሂብ ላይ እንዴት እንደሚታይ የሚያሳይ ምሳሌ ነው. 0% ለመድረስ መሞከር አያስፈልግም, የማይቻል ነው. ከ 30 - 100% ገደማ በሚሆንበት ጊዜ በጣም ጥሩ ነው, ይህ በአጭር ጊዜ ፍንዳታ ጊዜ ከማመቻቸት ሁነታ ያለጊዜው መውጣትን ለማስወገድ ይረዳል.

hbase.lru.cache.ከባድ.ማስወጣት.ከላይ.አካፋይ - ውጤቱን ምን ያህል በፍጥነት ማግኘት እንደምንፈልግ ያዘጋጃል። የእኛ ንባቦች በአብዛኛው ረጅም እንደሆኑ እና መጠበቅ እንደማንፈልግ በእርግጠኝነት ካወቅን ይህንን ምክንያት ማሳደግ እና ከፍተኛ አፈፃፀም በፍጥነት ማግኘት እንችላለን።

ለምሳሌ, ይህንን ቅንጅት = 0.01 አዘጋጅተናል. ይህ ማለት ኦቨርሄድ (ከላይ ይመልከቱ) በውጤቱ በዚህ ቁጥር ይባዛል እና የተሸጎጡ ብሎኮች መቶኛ ይቀንሳል። እንበል ኦቨርሄድ = 300%፣ እና ኮፊሸን = 0.01፣ ከዚያ የተሸጎጡ ብሎኮች መቶኛ በ3% ይቀንሳል።

ተመሳሳይ “የኋላ ግፊት” አመክንዮ እንዲሁ ከመጠን በላይ መተኮስን አሉታዊ እሴቶችን ይተገበራል። የአጭር ጊዜ የንባብ መጠን መለዋወጥ እና ማስወጣት ሁል ጊዜ ሊኖሩ ስለሚችሉ ይህ ዘዴ ከማመቻቸት ሁነታ ያለጊዜው መውጣትን ለማስወገድ ያስችላል። Backpressure የተገለበጠ አመክንዮ አለው፡ ከመጠን በላይ መተኮሱ በጠነከረ መጠን ብዙ ብሎኮች ይሸጎጣሉ።

የትግበራ ኮድ

        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;
       }

አሁን ይህንን ሁሉ በእውነተኛ ምሳሌ አስቡበት። የሚከተለው የሙከራ ሁኔታ አለን።

1. ስካን ማድረግ ይጀምሩ (25 ክሮች፣ ባች = 100)
2. ከ 5 ደቂቃዎች በኋላ, ባለብዙ-ግት (25 ክሮች, ባች = 100) ይጨምሩ.
3. ከ 5 ደቂቃዎች በኋላ, ባለብዙ-ግኝቶችን ያጥፉ (ስካን ብቻ እንደገና ይቀራል)

ሁለት ሩጫዎችን እናደርጋለን በመጀመሪያ hbase.lru.cache.heavy.eviction.count.limit = 10000 (ይህም ባህሪውን በትክክል ያሰናክላል) እና ከዚያም ገደብ = 0 አዘጋጅተናል (ያነቃል።)

ከታች ባሉት ምዝግብ ማስታወሻዎች ውስጥ, ባህሪው እንዴት እንደሚበራ እናያለን, Overshootingን ወደ 14-71% ዳግም ያስጀምረዋል. ከጊዜ ወደ ጊዜ ጭነቱ ይወድቃል, ይህም Backpressureን ያበራል እና HBase ተጨማሪ ብሎኮችን እንደገና ያበራል.

የክልል አገልጋይ መዝገብ
የተባረረ (ሜባ): 0፣ ሬሾ 0.0፣ ከአናት (%): -100፣ ከባድ የማስለቀቂያ ቆጣሪ: 0፣ የአሁኑ መሸጎጫ DataBlock (%): 100
የተባረረ (ሜባ): 0፣ ሬሾ 0.0፣ ከአናት (%): -100፣ ከባድ የማስለቀቂያ ቆጣሪ: 0፣ የአሁኑ መሸጎጫ DataBlock (%): 100
የተባረረ (ሜባ)፡ 2170፣ ጥምርታ 1.09፣ ከአናት (%)፡ 985፣ ከባድ የማስለቀቂያ ቆጣሪ፡ 1፣ የአሁኑ መሸጎጫ DataBlock (%)፡ 91 <ጅምር
የተባረረ (ሜባ)፡ 3763፣ ጥምርታ 1.08፣ ከአናት (%)፡ 1781፣ ከባድ የማስወጣት ቆጣሪ፡ 2፣ የአሁን መሸጎጫ DataBlock (%)፡ 76
የተባረረ (ሜባ)፡ 3306፣ ጥምርታ 1.07፣ ከአናት (%)፡ 1553፣ ከባድ የማስወጣት ቆጣሪ፡ 3፣ የአሁን መሸጎጫ DataBlock (%)፡ 61
የተባረረ (ሜባ)፡ 2508፣ ጥምርታ 1.06፣ ከአናት (%)፡ 1154፣ ከባድ የማስወጣት ቆጣሪ፡ 4፣ የአሁን መሸጎጫ DataBlock (%)፡ 50
የተባረረ (ሜባ)፡ 1824፣ ጥምርታ 1.04፣ ከአናት (%)፡ 812፣ ከባድ የማስወጣት ቆጣሪ፡ 5፣ የአሁን መሸጎጫ DataBlock (%)፡ 42
የተባረረ (ሜባ)፡ 1482፣ ጥምርታ 1.03፣ ከአናት (%)፡ 641፣ ከባድ የማስወጣት ቆጣሪ፡ 6፣ የአሁን መሸጎጫ DataBlock (%)፡ 36
የተባረረ (ሜባ)፡ 1140፣ ጥምርታ 1.01፣ ከአናት (%)፡ 470፣ ከባድ የማስወጣት ቆጣሪ፡ 7፣ የአሁን መሸጎጫ DataBlock (%)፡ 32
የተባረረ (ሜባ)፡ 913፣ ጥምርታ 1.0፣ ከአናት (%)፡ 356፣ ከባድ የማስወጣት ቆጣሪ፡ 8፣ የአሁን መሸጎጫ DataBlock (%)፡ 29
የተባረረ (ሜባ)፡ 912፣ ጥምርታ 0.89፣ ከአናት (%)፡ 356፣ ከባድ የማስወጣት ቆጣሪ፡ 9፣ የአሁን መሸጎጫ DataBlock (%)፡ 26
የተባረረ (ሜባ)፡ 684፣ ጥምርታ 0.76፣ ከአናት (%)፡ 242፣ ከባድ የማስወጣት ቆጣሪ፡ 10፣ የአሁን መሸጎጫ DataBlock (%)፡ 24
የተባረረ (ሜባ)፡ 684፣ ጥምርታ 0.61፣ ከአናት (%)፡ 242፣ ከባድ የማስወጣት ቆጣሪ፡ 11፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 456፣ ጥምርታ 0.51፣ ከአናት (%)፡ 128፣ ከባድ የማስወጣት ቆጣሪ፡ 12፣ የአሁን መሸጎጫ DataBlock (%)፡ 21
የተባረረ (ሜባ)፡ 456፣ ጥምርታ 0.42፣ ከአናት (%)፡ 128፣ ከባድ የማስወጣት ቆጣሪ፡ 13፣ የአሁን መሸጎጫ DataBlock (%)፡ 20
የተባረረ (ሜባ)፡ 456፣ ጥምርታ 0.33፣ ከአናት (%)፡ 128፣ ከባድ የማስወጣት ቆጣሪ፡ 14፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 15፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.32፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 16፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.31፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 17፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.3፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 18፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.29፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 19፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.27፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 20፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.25፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 21፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.24፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 22፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.22፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 23፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.21፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 24፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.2፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 25፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.17፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 26፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ): 456፣ ሬሾ 0.17፣ ከአናት (%): 128፣ ከባድ የማስለቀቂያ ቆጣሪ: 27፣ የአሁኑ መሸጎጫ DataBlock (%): 18 < ታክሏል ያገኛል (ነገር ግን ሠንጠረዥ አንድ ነው)
የተባረረ (ሜባ)፡ 456፣ ጥምርታ 0.15፣ ከአናት (%)፡ 128፣ ከባድ የማስወጣት ቆጣሪ፡ 28፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.13፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 29፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.11፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 30፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.09፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 31፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.08፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 32፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.07፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 33፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.06፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 34፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.05፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 35፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.05፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 36፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.04፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 37፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 109፣ ሬሾ 0.04፣ ከራስ በላይ (%): -46፣ ከባድ የማስለቀቂያ ቆጣሪ፡ 37፣ የአሁኑ መሸጎጫ DataBlock (%)፡ 22 <የኋላ ግፊት
የተባረረ (ሜባ)፡ 798፣ ጥምርታ 0.24፣ ከአናት (%)፡ 299፣ ከባድ የማስወጣት ቆጣሪ፡ 38፣ የአሁን መሸጎጫ DataBlock (%)፡ 20
የተባረረ (ሜባ)፡ 798፣ ጥምርታ 0.29፣ ከአናት (%)፡ 299፣ ከባድ የማስወጣት ቆጣሪ፡ 39፣ የአሁን መሸጎጫ DataBlock (%)፡ 18
የተባረረ (ሜባ)፡ 570፣ ጥምርታ 0.27፣ ከአናት (%)፡ 185፣ ከባድ የማስወጣት ቆጣሪ፡ 40፣ የአሁን መሸጎጫ DataBlock (%)፡ 17
የተባረረ (ሜባ)፡ 456፣ ጥምርታ 0.22፣ ከአናት (%)፡ 128፣ ከባድ የማስወጣት ቆጣሪ፡ 41፣ የአሁን መሸጎጫ DataBlock (%)፡ 16
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.16፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 42፣ የአሁን መሸጎጫ DataBlock (%)፡ 16
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.11፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 43፣ የአሁን መሸጎጫ DataBlock (%)፡ 16
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.09፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 44፣ የአሁን መሸጎጫ DataBlock (%)፡ 16
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.07፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 45፣ የአሁን መሸጎጫ DataBlock (%)፡ 16
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.05፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 46፣ የአሁን መሸጎጫ DataBlock (%)፡ 16
የተባረረ (ሜባ)፡ 222፣ ጥምርታ 0.04፣ ከአናት (%)፡ 11፣ ከባድ የማስወጣት ቆጣሪ፡ 47፣ የአሁን መሸጎጫ DataBlock (%)፡ 16
የተባረረ (ሜባ): 104፣ ሬሾ 0.03፣ ከአናት (%): -48፣ ከባድ የማስለቀቂያ ቆጣሪ: 47፣ የአሁኑ መሸጎጫ DataBlock (%): 21 <ማቋረጥ ያገኛል
የተባረረ (ሜባ)፡ 684፣ ጥምርታ 0.2፣ ከአናት (%)፡ 242፣ ከባድ የማስወጣት ቆጣሪ፡ 48፣ የአሁን መሸጎጫ DataBlock (%)፡ 19
የተባረረ (ሜባ)፡ 570፣ ጥምርታ 0.23፣ ከአናት (%)፡ 185፣ ከባድ የማስወጣት ቆጣሪ፡ 49፣ የአሁን መሸጎጫ DataBlock (%)፡ 18
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.22፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 50፣ የአሁን መሸጎጫ DataBlock (%)፡ 18
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.21፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 51፣ የአሁን መሸጎጫ DataBlock (%)፡ 18
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.2፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 52፣ የአሁን መሸጎጫ DataBlock (%)፡ 18
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.18፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 53፣ የአሁን መሸጎጫ DataBlock (%)፡ 18
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.16፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 54፣ የአሁን መሸጎጫ DataBlock (%)፡ 18
የተባረረ (ሜባ)፡ 228፣ ጥምርታ 0.14፣ ከአናት (%)፡ 14፣ ከባድ የማስወጣት ቆጣሪ፡ 55፣ የአሁን መሸጎጫ DataBlock (%)፡ 18
የተባረረ (ሜባ)፡ 112፣ ሬሾ 0.14፣ ከራስ በላይ (%): -44፣ ከባድ የማስለቀቂያ ቆጣሪ፡ 55፣ የአሁኑ መሸጎጫ DataBlock (%)፡ 23 <የኋላ ግፊት
የተባረረ (ሜባ)፡ 456፣ ጥምርታ 0.26፣ ከአናት (%)፡ 128፣ ከባድ የማስወጣት ቆጣሪ፡ 56፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.31፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 57፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 58፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 59፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 60፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 61፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 62፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 63፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.32፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 64፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 65፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 66፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.32፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 67፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 68፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.32፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 69፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.32፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 70፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 71፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 72፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 73፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 74፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 75፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ)፡ 342፣ ጥምርታ 0.33፣ ከአናት (%)፡ 71፣ ከባድ የማስወጣት ቆጣሪ፡ 76፣ የአሁን መሸጎጫ DataBlock (%)፡ 22
የተባረረ (ሜባ): 21፣ ሬሾ 0.33፣ ከአናት (%): -90፣ ከባድ የማስለቀቂያ ቆጣሪ: 76፣ የአሁኑ መሸጎጫ DataBlock (%): 32
የተባረረ (ሜባ): 0፣ ሬሾ 0.0፣ ከአናት (%): -100፣ ከባድ የማስለቀቂያ ቆጣሪ: 0፣ የአሁኑ መሸጎጫ DataBlock (%): 100
የተባረረ (ሜባ): 0፣ ሬሾ 0.0፣ ከአናት (%): -100፣ ከባድ የማስለቀቂያ ቆጣሪ: 0፣ የአሁኑ መሸጎጫ DataBlock (%): 100

ፍተሻው የሚያስፈልገው ተመሳሳይ ሂደትን በመሸጎጫው ሁለት ክፍሎች መካከል ያለውን ግንኙነት በግራፍ መልክ ለማሳየት ነው - ነጠላ (ማንም እስካሁን ያልጠየቀባቸው ብሎኮች) እና ብዙ (“የተጠየቀው” ውሂብ ቢያንስ አንድ ጊዜ። እዚህ ተከማችተዋል):

እና በመጨረሻም, መለኪያዎች በግራፍ መልክ እንዴት እንደሚሠሩ. ለማነፃፀር ፣መሸጎጫው መጀመሪያ ላይ ሙሉ በሙሉ ጠፍቷል ፣ከዚያም የ HBase ጅምር በመሸጎጥ እና የማመቻቸት መጀመሪያ በ 5 ደቂቃዎች (30 የማስወጣት ዑደቶች) መዘግየት ነበር።

ሙሉ ኮድ በ Pull Request ውስጥ ይገኛል። HBASE-23887 በ github ላይ።

ነገር ግን በሴኮንድ 300 ሺህ ንባቦች በእነዚህ ሁኔታዎች ውስጥ በዚህ ሃርድዌር ላይ ሊጨመቁ የሚችሉት ብቻ አይደሉም። እውነታው ግን በኤችዲኤፍኤስ በኩል መረጃን ማግኘት ሲፈልጉ የ ShortCircuitCache (ከዚህ በኋላ SSC) ዘዴ ጥቅም ላይ ይውላል, ይህም የአውታረ መረብ ግንኙነቶችን በማስወገድ በቀጥታ መረጃን ለመድረስ ያስችላል.

ፕሮፋይሊንግ እንደሚያሳየው ይህ ዘዴ ትልቅ ትርፍ ቢያስገኝም, በተወሰነ ጊዜም ማነቆ ይሆናል, ምክንያቱም ሁሉም ማለት ይቻላል ከባድ ስራዎች በመቆለፊያ ውስጥ ይከሰታሉ, ይህም ብዙ ጊዜ ወደ መቆለፊያዎች ይመራል.

ይህንን በመገንዘብ ችግሩን ማስቀረት የሚቻለው ገለልተኛ የሆኑ SSCs በመፍጠር ነው።

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)];
}

አሁን መሞከር መጀመር ይችላሉ። ይህንን ለማድረግ, ፋይሎችን ከኤችዲኤፍኤስ በቀላል ባለ ብዙ ክር መተግበሪያ እናነባለን. መለኪያዎችን እናዘጋጃለን-

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 መጨመር አንድ መሸጎጫ ብቻ ሲኖር ከጉዳዩ አንፃር የሚሰጠውን ፍጥነት ያሳያል።

ግራፉን እንዴት ማንበብ ይቻላል፡ 100k በ64K blocks በአንድ መሸጎጫ ንባብ ለመጨረስ 78 ሰከንድ ይወስዳል። በ5 መሸጎጫዎች 16 ሰከንድ ይወስዳል። እነዚያ። ~ 5 ጊዜ ማፋጠን አለ። ከግራፉ ላይ እንደምታዩት በትንሽ ትይዩ ንባቦች ላይ ውጤቱ ብዙም አይታይም ፣ ክሩ ሲነበብ ከ 50 በላይ በሆነ ጊዜ ጉልህ ሚና መጫወት ይጀምራል ። በተጨማሪም የኤስ.ኤስ.ሲ. 6 እና ከዚያ በላይ በከፍተኛ ሁኔታ ያነሰ የአፈፃፀም ትርፍ ይሰጣል።

ማስታወሻ 1 የፈተና ውጤቶቹ በጣም ተለዋዋጭ ስለሆኑ (ከዚህ በታች ይመልከቱ) ፣ 3 ጅምር ተካሂደዋል እና የተገኙት እሴቶች አማካይ ናቸው።

ማስታወሻ 2፡ ከዘፈቀደ መዳረሻ መቼት የተገኘው የአፈጻጸም ትርፍ ተመሳሳይ ነው፣ ምንም እንኳን መዳረሻው ራሱ ትንሽ ቀርፋፋ ነው።

ሆኖም፣ ከHBase ጋር ካለው ሁኔታ በተለየ ይህ ማጣደፍ ሁልጊዜ ነፃ እንዳልሆነ መገለጽ አለበት። እዚህ እኛ በመቆለፊያዎች ላይ ከመንጠልጠል ይልቅ የሲፒዩውን ስራ የመስራት ችሎታን የበለጠ "መክፈት" አለብን።

እዚህ በአጠቃላይ ፣ የመሸጎጫዎች ብዛት መጨመር በሲፒዩ አጠቃቀም ላይ በግምት ተመጣጣኝ ጭማሪ እንደሚሰጥ ማየት ይችላሉ። ይሁን እንጂ በርካታ ተጨማሪ አሸናፊ ጥምረት አሉ.

ለምሳሌ፣ ቅንብሩን ጠለቅ ብለን እንመልከተው SSC = 3. በክልል ላይ ያለው የአፈጻጸም ጭማሪ 3.3 ጊዜ ያህል ነው። ከዚህ በታች ያሉት የሶስቱም የተለያዩ ሩጫዎች ውጤቶች ናቸው።

የሲፒዩ ፍጆታ በ2.8 ጊዜ ገደማ ያድጋል። ልዩነቱ በጣም ትልቅ አይደለም፣ ነገር ግን ትንሽዬ Greta ደስተኛ ነች እና ምናልባት ትምህርት ቤት እና ትምህርቶችን ለመከታተል ጊዜ ሊኖር ይችላል።

ስለዚህ ይህ HDFS የጅምላ መዳረሻን (ለምሳሌ ስፓርክ ወዘተ) በሚጠቀም ማንኛውም መሳሪያ ላይ አወንታዊ ተጽእኖ ይኖረዋል፣ የመተግበሪያው ኮድ ቀላል ከሆነ (ማለትም በኤችዲኤፍኤስ ደንበኛ በኩል መሰካት) እና ነፃ የሲፒዩ ሃይል እስካለ ድረስ። ለመፈተሽ፣ ከHBase ለማንበብ የBlockCache ማመቻቸት እና SSC ማስተካከል ምን ውጤት እንደሚሰጥ እንፈትሽ።

እዚህ ማየት ይችላሉ እንደዚህ ባሉ ሁኔታዎች ውጤቱ እንደ የተጣራ ሙከራዎች (ያለ ምንም ሂደት ማንበብ) ትልቅ አይደለም ፣ ግን እዚህ ተጨማሪ 80 ኪ. አንድ ላይ፣ ሁለቱም ማትባቶች እስከ 4 ጊዜ ፍጥነትን ይሰጣሉ።

ለዚህ ማመቻቸት PR ተሠርቷል። [ኤችዲኤፍኤስ-15202]የተዋሃደ እና ይህ ተግባር ወደፊት በሚለቀቁት እትሞች ላይ ይገኛል።

እና በመጨረሻም፣ ተመሳሳይ ሰፊ-አምድ ዳታቤዝ ካሳንድራ እና ኤችቤዝ የንባብ አፈጻጸምን ማወዳደር አስደሳች ነበር።

ይህንን ለማድረግ፣ የመደበኛው የYCSB ጭነት መሞከሪያ መገልገያ አጋጣሚዎች ከሁለት አስተናጋጆች (በአጠቃላይ 800 ክሮች) ተጀምረዋል። በአገልጋይ በኩል - 4 የRegionalServer እና ካሳንድራ በ 4 አስተናጋጆች ላይ (ደንበኞች ተጽኖአቸውን ለማስወገድ በሚሮጡበት አይደለም)። ንባቦች ከመጠኑ ሠንጠረዦች መጡ፡-

HBase - 300 ጊባ በኤችዲኤፍኤስ (100 ጂቢ ጥሬ መረጃ)

ካሳንድራ - 250 ጊባ (ማባዛት ምክንያት = 3)

እነዚያ። መጠኑ ተመሳሳይ ነበር (በHBase ትንሽ ተጨማሪ)።

የ Hbase አማራጮች

dfs.client.short.circuit.num = 5 (HDFS ደንበኛ ማመቻቸት)

hbase.lru.cache.heavy.eviction.count.limit = 30 - ይህ ማለት ማጣበቂያው ከ 30 ማባረር በኋላ መሥራት ይጀምራል (~ 5 ደቂቃዎች)

hbase.lru.cache.ከባድ.ማስወጣት.mb.size.limit = 300 - የመሸጎጫ እና የማስወጣት ዒላማ መጠን

የYCSB ምዝግብ ማስታወሻዎች ተተንትነው ወደ ኤክሴል ገበታዎች ተሰብስበዋል።

እንደሚመለከቱት ፣ የማመቻቸት መረጃው በእነዚህ ሁኔታዎች ውስጥ የእነዚህን የውሂብ ጎታዎች አፈፃፀም እኩል ለማድረግ እና በሰከንድ 450 ንባቦችን ለማሳካት ያስችላል።

ይህ መረጃ ለአፈፃፀም በሚያስደስት ትግል ሂደት ውስጥ ለአንድ ሰው ጠቃሚ ሊሆን እንደሚችል ተስፋ እናደርጋለን።

ምንጭ: hab.com