لوړ فعالیت یو له مهمو اړتیاو څخه دی کله چې د لوی ډیټا سره کار کوي. په سبربینک کې د ډیټا بارولو ډیپارټمنټ کې، موږ نږدې ټولې راکړې ورکړې زموږ د هډوپ پراساس ډیټا کلاوډ ته پمپ کوو او له همدې امله د معلوماتو واقعیا لوی جریان سره معامله کوو. په طبیعي ډول ، موږ تل د فعالیت ښه کولو لپاره لارو په لټه کې یو ، او اوس موږ غواړو تاسو ته ووایو چې څنګه موږ د RegionServer HBase او HDFS پیرودونکي پیچ کولو اداره کړې ، له دې امله موږ وکولی شو د لوستلو عملیاتو سرعت د پام وړ لوړ کړو.
په هرصورت، مخکې له دې چې د پرمختګ جوهر ته لاړ شئ، دا د محدودیتونو په اړه د خبرو ارزښت لري چې په اصل کې، که تاسو په HDD کې ناست یاست، مخنیوی نشي کولی.
ولې HDD او ګړندي بې ترتیبه لاسرسي لوستل غیر مطابقت لري
لکه څنګه چې تاسو پوهیږئ، HBase، او ډیری نور ډیټابیسونه، ډاټا د څو لسګونو کیلوبایټ اندازې په بلاکونو کې ذخیره کوي. په ډیفالټ دا د 64 KB په اړه دی. اوس راځئ چې تصور وکړو چې موږ یوازې 100 بایټس ترلاسه کولو ته اړتیا لرو او موږ له HBase څخه غوښتنه کوو چې موږ ته د یوې ټاکلې کیلي په کارولو سره دا معلومات راکړئ. څرنګه چې په HFiles کې د بلاک اندازه 64 KB ده، غوښتنه به د اړتیا په پرتله 640 ځله لویه وي (یوازې یوه دقیقه!).
بیا، ځکه چې غوښتنه به د HDFS او د هغې د میټاډاټا کیشینګ میکانیزم له لارې تیریږي ShortCircuitCache (کوم چې فایلونو ته مستقیم لاسرسي ته اجازه ورکوي) ، دا د ډیسک څخه دمخه د 1 MB لوستلو لامل کیږي. په هرصورت، دا د پیرامیټر سره تنظیم کیدی شي dfs.client.read.shortcircuit.buffer.size او په ډیری قضیو کې دا معنی لري چې دا ارزښت کم کړي، د بیلګې په توګه 126 KB ته.
راځئ چې ووایو چې موږ دا کوو، مګر سربیره پردې، کله چې موږ د جاوا اپی له لارې د ډیټا لوستل پیل کوو، لکه د FileChannel.read په څیر افعال او د عملیاتي سیسټم څخه وغواړو چې د ټاکل شوي مقدار ډیټا ولولي، دا "یوازې په صورت کې" 2 ځله لوستل کیږي. , i.e. زموږ په قضیه کې 256 KB. دا ځکه چې جاوا د دې چلند مخنیوي لپاره د FADV_RANDOM بیرغ تنظیم کولو لپاره اسانه لار نلري.
د پایلې په توګه، زموږ د 100 بایټ ترلاسه کولو لپاره، 2600 ځله نور د هود لاندې لوستل کیږي. داسې بریښي چې حل څرګند دی ، راځئ چې د بلاک اندازه یو کیلوبایټ ته راټیټ کړو ، ذکر شوی بیرغ تنظیم کړو او د روښانتیا عالي سرعت ترلاسه کړو. مګر ستونزه دا ده چې د بلاک اندازې 2 ځله کمولو سره ، موږ د وخت په هر واحد کې د لوستلو بایټ شمیر 2 ځله کموو.
د FADV_RANDOM بیرغ تنظیم کولو څخه ځینې لاسته راوړنې ترلاسه کیدی شي ، مګر یوازې د لوړ ملټي تھریډینګ سره او د 128 KB بلاک اندازې سره ، مګر دا اعظمي حد د څو سلنې سلنې دی:
ازموینې په 100 فایلونو کې ترسره شوې، هر یو د 1 GB اندازه کې او په 10 HDDs کې موقعیت لري.
راځئ چې هغه څه محاسبه کړو چې موږ کولی شو په اصولو کې په دې سرعت حساب وکړو:
راځئ چې ووایو چې موږ د 10 ډیسکونو څخه د 280 MB/sec په سرعت سره لوستل کوو، د بیلګې په توګه. 3 ملیون ځله 100 بایټ. مګر لکه څنګه چې موږ په یاد لرو، هغه معلومات چې موږ ورته اړتیا لرو د لوستلو په پرتله 2600 ځله کم دي. په دې توګه، موږ 3 ملیون په 2600 ویشو او ترلاسه کوو په هره ثانیه کې 1100 ریکارډونه.
خپګان، دا نه ده؟ دا طبیعت دی ناټاکلي رسي په HDD کې ډیټا ته لاسرسی - د بلاک اندازې په پام کې نیولو پرته. دا د تصادفي لاسرسي فزیکي حد دی او هیڅ ډیټابیس نشي کولی د داسې شرایطو لاندې نور فشار راوړي.
بیا څنګه ډیټابیس ډیر لوړ سرعت ترلاسه کوي؟ د دې پوښتنې د ځواب لپاره، راځئ وګورو چې په لاندې انځور کې څه پیښیږي:
دلته موږ ګورو چې د لومړیو څو دقیقو لپاره سرعت واقعیا په هر ثانیه کې د زرو ریکارډونو په اړه دی. په هرصورت، د دې حقیقت له امله چې د غوښتنې په پرتله ډیر څه لوستل کیږي، ډاټا د عملیاتي سیسټم (لینکس) په بف / کیچ کې پای ته رسیږي او سرعت یې په هر ثانیه کې 60 زرو ته لوړیږي.
پدې توګه ، نور به موږ یوازې هغه ډیټا ته د لاسرسي ګړندي کولو سره معامله وکړو چې د OS کیچ کې دي یا د ورته لاسرسي سرعت SSD/NVMe ذخیره کولو وسیلو کې موقعیت لري.
زموږ په قضیه کې، موږ به د 4 سرورونو په بنچ کې ازموینې ترسره کړو، چې هر یو یې په لاندې ډول چارج کیږي:
CPU: Xeon E5-2680 v4 @ 2.40GHz 64 تارونه.
حافظه: 730 GB
جاوا نسخه: 1.8.0_111
او دلته مهم ټکی په جدولونو کې د معلوماتو مقدار دی چې لوستلو ته اړتیا لري. حقیقت دا دی چې که تاسو د میز څخه ډاټا ولولئ چې په بشپړ ډول د HBase کیچ کې ځای په ځای شوي، نو دا به حتی د عملیاتي سیسټم بف / کیچ څخه لوستلو ته هم نه راځي. ځکه چې HBase په ډیفالټ ډول 40٪ حافظه د بلاک کیچ په نوم جوړښت ته تخصیص کوي. په اصل کې دا یو ConcurrentHashMap دی، چیرې چې کیلي د فایل نوم + د بلاک آفسیټ دی، او ارزښت په دې آفسیټ کې اصلي ډاټا ده.
په دې توګه، کله چې یوازې د دې جوړښت څخه لوستل، موږ لکه په هره ثانیه کې د یو ملیون غوښتنې. مګر راځئ تصور وکړو چې موږ نشو کولی سلګونه ګیګابایټ حافظه یوازې د ډیټابیس اړتیاو لپاره تخصیص کړو ، ځکه چې پدې سرورونو کې ډیر نور ګټور شیان شتون لري.
د مثال په توګه، زموږ په قضیه کې، په یو RS کې د بلاک کیچ حجم شاوخوا 12 GB دی. موږ په یوه نوډ کې دوه RS کښته کړل، د بیلګې په توګه. 96 GB په ټولو نوډونو کې د بلاک کیچ لپاره ځانګړي شوي. او دلته څو ځله ډیر ډیټا شتون لري، د بیلګې په توګه، اجازه راکړئ چې دا 4 میزونه وي، هر یو 130 سیمې وي، په کوم کې چې فایلونه 800 MB اندازه وي، د FAST_DIFF لخوا فشار شوي، د بیلګې په توګه. ټولټال 410 GB (دا خالص معلومات دي، د بیلګې په توګه د نقل کولو فکتور په پام کې نیولو پرته).
په دې توګه، بلاک کیچ د ټول ډیټا حجم یوازې 23٪ دی او دا د هغه څه اصلي شرایطو ته خورا نږدې دی چې د BigData په نوم یادیږي. او دا هغه ځای دی چیرې چې ساتیري پیل کیږي - ځکه چې په څرګنده توګه ، څومره چې لږ کیچ هټ کیږي ، د فعالیت خراب دی. په هرصورت، که تاسو له لاسه ورکړئ، تاسو به ډیر کار وکړئ - د بیلګې په توګه. د زنګ وهلو سیسټم فعالیتونو ته لاړ شئ. په هرصورت، دا نشي مخنیوی کیدی، نو راځئ چې یو بشپړ مختلف اړخ وګورو - د کیچ دننه ډاټا ته څه پیښیږي؟
راځئ چې وضعیت ساده کړو او فرض کړو چې موږ یوه زیرمه لرو چې یوازې د 1 څیز سره سمون لري. دلته یو مثال دی چې څه به پیښ شي کله چې موږ د ډیټا حجم سره د کیچ څخه 3 ځله لوی کار کولو هڅه کوو ، موږ به یې وکړو:
1. بلاک 1 په کیچ کې ځای په ځای کړئ
2. د کیچ څخه بلاک 1 لرې کړئ
3. بلاک 2 په کیچ کې ځای په ځای کړئ
4. د کیچ څخه بلاک 2 لرې کړئ
5. بلاک 3 په کیچ کې ځای په ځای کړئ
5 کړنې بشپړې شوې! په هرصورت، دا وضعیت نورمال نشي بلل کیدی؛ په حقیقت کې، موږ HBase مجبور یو چې د بشپړ بې ګټې کار یوه ډله ترسره کړو. دا په دوامداره توګه د OS کیچ څخه ډاټا لوستل کوي، دا په بلاک کیچ کې ځای په ځای کوي، یوازې د دې لپاره چې نږدې سمدلاسه یې وباسي ځکه چې د معلوماتو نوې برخه رارسیدلې ده. د پوسټ په پیل کې حرکت د ستونزې جوهر ښیې - د کثافاتو راټولونکی په پیمانه روان دی ، فضا ګرمه ده ، په لرې او ګرم سویډن کې کوچنۍ ګریټا خپه کیږي. او موږ د آی ټي خلک واقعیا دا نه خوښوي کله چې ماشومان غمجن وي ، نو موږ د دې په اړه فکر کوو چې موږ یې په اړه څه کولی شو.
څه که تاسو ټول بلاکونه په زیرمه کې نه واچوئ ، مګر یوازې د دوی یوه ټاکلې سلنه ، ترڅو کیچ ډک نشي؟ راځئ چې په ساده ډول د 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 جوړ کړ او بلاک کیچ یو څه لږ کارول شوی و. اوس راځئ چې دا 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 ثانیو کې حساب کوو چې څومره بایټونه وو. د فورمول په کارولو سره ایستل شوی:
Overhead = د وړیا بایټس رقم (MB) * 100 / حد (MB) - 100;
که په حقیقت کې 2000 MB ویستل شوي وي، نو د سر سر مساوي دی:
2000 * 100 / 500 - 100 = 300٪
الګوریتم هڅه کوي چې له څو څخه زیات سلنې وساتي، نو دا فیچر به د کیش شوي بلاکونو فیصدي کمه کړي، په دې توګه د اتوماتیک ټونینګ میکانیزم پلي کوي.
که څه هم، که بار راټیټ شي، راځئ چې ووایو یوازې 200 MB ویستل شوي او Overhead منفي کیږي (د تش په نامه نظارت):
200*100/500 - 100 = -60%
برعکس، خصوصیت به د زیرمه شوي بلاکونو فیصده زیاته کړي تر هغه چې سر مثبت شي.
لاندې یو مثال دی چې دا څنګه په ریښتیني معلوماتو کې ښکاري. اړتیا نشته چې 0٪ ته د رسیدو هڅه وکړئ، دا ناشونې ده. دا خورا ښه دی کله چې دا شاوخوا 30 - 100٪ وي، دا د لنډ مهاله سرجونو په جریان کې د اصلاح کولو حالت څخه د وخت څخه مخکې وتلو څخه مخنیوي کې مرسته کوي.
hbase.lru.cache.heavy.eviction.overhead.coefficient - ټاکي چې موږ څومره ژر پایله ترلاسه کول غواړو. که موږ په ډاډه توګه پوه شو چې زموږ لوستل اکثرا اوږد دي او نه غواړو انتظار وکړو، موږ کولی شو دا تناسب زیات کړو او لوړ فعالیت ګړندی ترلاسه کړو.
د مثال په توګه، موږ دا کوفینټ = 0.01 ټاکلو. دا پدې مانا ده چې Overhead (پورته وګورئ) به د دې شمیرې سره د پایلې پایلې سره ضرب شي او د زیرمه شوي بلاکونو سلنه به کمه شي. راځئ فرض کړو چې Overhead = 300٪ او coefficient = 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 ټاکل (فعالوي).
په لاندې لاګونو کې موږ ګورو چې څنګه فیچر فعال شوی او Overshooting 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 له لارې ډیټا ته لاسرسي ته اړتیا لرئ ، د شارټ سرکیټ کیچ (له دې وروسته د 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)];
}
اوس تاسو کولی شئ ازموینه پیل کړئ. د دې کولو لپاره، موږ به د 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 څخه ډیر تار لوستل کیږي. دا هم د پام وړ ده چې د SSCs شمیر له 6 څخه ډیریږي. او پورته د پام وړ کوچني فعالیت زیاتوالی ورکوي.
یادونه 1: څرنګه چې د ازموینې پایلې خورا بې ثباته دي (لاندې وګورئ)، 3 منډې ترسره شوې او د پایلې ارزښتونه اوسط شوي.
یادونه 2: د تصادفي لاسرسي تنظیم کولو څخه د فعالیت لاسته راوړنه ورته ده ، که څه هم لاسرسی پخپله یو څه ورو دی.
په هرصورت، دا باید روښانه شي چې د HBase سره د قضیې برعکس، دا سرعت تل وړیا نه وي. دلته موږ د قلفونو ځړولو پرځای د CPU وړتیا د ډیر کار کولو وړتیا "انلاک" کوو.
دلته تاسو لیدلی شئ چې په عموم کې ، د کیچونو شمیر کې زیاتوالی د CPU کارولو کې نږدې متناسب زیاتوالی ورکوي. په هرصورت، یو څه نور ګټونکي ترکیبونه شتون لري.
د مثال په توګه، راځئ چې د SSC = 3 ترتیب ته نږدې کتنه وکړو. په رینج کې د فعالیت زیاتوالی شاوخوا 3.3 ځله دی. لاندې د ټولو دریو جلا منډو پایلې دي.
پداسې حال کې چې د CPU مصرف شاوخوا 2.8 ځله ډیریږي. توپیر خورا لوی نه دی، مګر کوچنۍ ګریټا لا دمخه خوشحاله ده او ممکن وخت ولري چې ښوونځي ته لاړ شي او درسونه واخلي.
په دې توګه، دا به د هرې وسیلې لپاره مثبت اغیزه ولري چې HDFS ته لوی لاسرسی کاروي (د مثال په توګه سپارک، او داسې نور)، په دې شرط چې د غوښتنلیک کوډ لږ وزن ولري (د بیلګې په توګه پلګ د HDFS پیرودونکي اړخ کې وي) او وړیا CPU ځواک شتون لري. . د چک کولو لپاره، راځئ چې ازموینه وکړو چې د HBase څخه د لوستلو لپاره د بلاک کیچ اصلاح او SSC ټونینګ ګډ کارول به څه اغیزه ولري.
دا لیدل کیدی شي چې په داسې شرایطو کې اغیز دومره لوی ندی لکه څنګه چې په اصلاح شوي ازموینو کې (پرته له پروسس کولو لوستل) ، مګر دا خورا ممکنه ده چې دلته اضافي 80K نچوڑ کړئ. په ګډه، دواړه اصلاح تر 4x سرعت وړاندې کوي.
د دې اصلاح لپاره یو PR هم جوړ شوی و ، کوم چې یوځای شوی او دا فعالیت به په راتلونکو خپرونو کې شتون ولري.
او په نهایت کې ، دا په زړه پوري وه چې د ورته پراخه کالم ډیټابیس ، کاسندرا او HBase لوستلو فعالیت پرتله کړئ.
د دې کولو لپاره، موږ د دوه کوربه (په مجموعي ډول 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