وڏي ڊيٽا سان ڪم ڪرڻ وقت اعلي ڪارڪردگي اهم ضرورتن مان هڪ آهي. Sberbank ۾ ڊيٽا لوڊ ڪرڻ واري کاتي ۾، اسان تقريبن سڀني ٽرانزيڪشن کي اسان جي Hadoop-based Data Cloud ۾ پمپ ڪريون ٿا ۽ ان ڪري معلومات جي واقعي وڏي وهڪري سان معاملو ڪريو. قدرتي طور تي، اسان هميشه ڪارڪردگي کي بهتر ڪرڻ جا طريقا ڳوليندا آهيون، ۽ هاڻي اسان توهان کي ٻڌائڻ چاهيون ٿا ته اسان ڪيئن منظم ڪيو RegionServer HBase ۽ HDFS ڪلائنٽ، جنهن جي مهرباني اسان پڙهڻ جي عملن جي رفتار کي خاص طور تي وڌائڻ جي قابل ٿي ويا آهيون.
تنهن هوندي، سڌارن جي جوهر ڏانهن وڃڻ کان اڳ، اهو پابنديون بابت ڳالهائڻ جي قابل آهي، اصول ۾، جيڪڏهن توهان HDD تي ويهندا آهيو، ان کي روڪي نه ٿو سگهجي.
ڇو HDD ۽ تيز رينڊم رسائي ريڊس غير مطابقت رکندڙ آهن
جيئن توهان کي خبر آهي، HBase، ۽ ٻيا ڪيترائي ڊيٽابيس، ڊيٽا کي ڪيترن ئي ڏهن ڪلوبائٽس جي بلاڪن ۾ ذخيرو ڪندا آهن. ڊفالٽ طور اهو اٽڪل 64 KB آهي. هاڻي اچو ته تصور ڪريون ته اسان کي صرف 100 بائيٽ حاصل ڪرڻ گهرجن ۽ اسان HBase کان پڇون ٿا ته اها ڊيٽا اسان کي هڪ مخصوص ڪيئي استعمال ڪندي ڏيو. جيئن ته HFiles ۾ بلاڪ سائيز 64 KB آهي، درخواست ضروري کان 640 ڀيرا وڏي (صرف هڪ منٽ!) هوندي.
اڳيون، ڇو ته درخواست HDFS ۽ ان جي ميٽا ڊيٽا ڪيشنگ ميڪانيزم ذريعي ٿيندي شارٽ سرڪٽ ڪيچ (جيڪو فائلن تائين سڌو رسائي جي اجازت ڏئي ٿو)، هي ڊسڪ مان اڳ ۾ ئي 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 / سيڪنڊ جي رفتار سان پڙهون ٿا، يعني. 3 ملين ڀيرا 100 بائيٽ. پر جيئن اسان کي ياد آهي، ڊيٽا جيڪا اسان کي گهربل آهي اها 2600 ڀيرا گهٽ آهي جيڪا پڙهي وڃي ٿي. ان ڪري، اسان 3 ملين کي 2600 ذريعي ورهايو ۽ حاصل ڪيو 1100 رڪارڊ في سيڪنڊ.
اداس ڪندڙ، اهو ناهي؟ اها فطرت آهي بي ترتيب رسائي HDD تي ڊيٽا تائين رسائي - بلاڪ سائيز کان سواء. هي بي ترتيب رسائي جي جسماني حد آهي ۽ ڪو به ڊيٽابيس اهڙين حالتن ۾ وڌيڪ نچوض نٿو ڪري سگهي.
پوء ڪيئن ڊيٽابيس تمام تيز رفتار حاصل ڪن ٿا؟ هن سوال جو جواب ڏيڻ لاء، اچو ته ڏسو ته هيٺ ڏنل تصوير ۾ ڇا ٿي رهيو آهي:
هتي اسان ڏسون ٿا ته پهرين چند منٽن لاءِ رفتار واقعي هڪ هزار رڪارڊ في سيڪنڊ آهي. بهرحال، اڳتي هلي، ان حقيقت جي ڪري ته گهڻو ڪجهه پڙهيو ويو آهي ان کان وڌيڪ درخواست ڪئي وئي، ڊيٽا ختم ٿي وڃي ٿي بف/ڪيش ۾ آپريٽنگ سسٽم (لينڪس) ۽ رفتار وڌي ٿي 60 هزار في سيڪنڊ کان وڌيڪ مهذب.
ان ڪري، اڳتي اسان صرف ڊيٽا تائين رسائي کي تيز ڪرڻ سان معاملو ڪنداسين جيڪو OS ڪيش ۾ آهي يا SSD/NVMe اسٽوريج ڊوائيسز ۾ موجود آهي نسبتا رسائي جي رفتار جي.
اسان جي صورت ۾، اسان 4 سرورز جي بينچ تي ٽيسٽ ڪنداسين، جن مان هر هڪ هيٺ ڏنل چارج آهي:
سي پي يو: Xeon E5-2680 v4 @ 2.40GHz 64 موضوع.
ياداشت: 730 GB.
جاوا ورزن: 1.8.0_111
۽ هتي اهم نقطو جدولن ۾ ڊيٽا جو مقدار آهي جنهن کي پڙهڻ جي ضرورت آهي. حقيقت اها آهي ته جيڪڏهن توهان هڪ ٽيبل مان ڊيٽا پڙهو ٿا جيڪو مڪمل طور تي HBase ڪيش ۾ رکيل آهي، ته پوءِ اهو آپريٽنگ سسٽم جي بف/ڪيش مان پڙهڻ ۾ به نه ايندو. ڇو ته HBase ڊفالٽ طور 40 سيڪڙو ميموري مختص ڪري ٿو بلاڪ ڪيچ نالي هڪ ڍانچي کي. لازمي طور تي هي هڪ ConcurrentHashMap آهي، جتي اهم فائل جو نالو آهي + بلاڪ جو آفسيٽ، ۽ قيمت هن آفسٽ تي حقيقي ڊيٽا آهي.
اهڙيء طرح، جڏهن صرف هن ساخت مان پڙهي، اسان ، هڪ ملين درخواستن وانگر في سيڪنڊ. پر اچو ته تصور ڪريون ته اسان صرف ڊيٽابيس جي ضرورتن لاءِ سوين گيگا بائيٽ ميموري مختص نٿا ڪري سگهون، ڇاڪاڻ ته انهن سرورن تي هلندڙ ٻيون به ڪيتريون ئي ڪارائتيون شيون آهن.
مثال طور، اسان جي صورت ۾، هڪ RS تي BlockCache جو مقدار اٽڪل 12 GB آهي. اسان هڪ نوڊ تي ٻه RS لينڊ ڪيو، يعني. 96 GB سڀني نوڊس تي BlockCache لاءِ مختص ڪيا ويا آهن. ۽ هتي ڪيترائي ڀيرا وڌيڪ ڊيٽا آهي، مثال طور، ان کي 4 جدولن، 130 علائقا هر هڪ، جنهن ۾ فائلون 800 MB سائيز ۾ آهن، FAST_DIFF پاران دٻايو ويو آهي، يعني. مجموعي طور تي 410 GB (هي خالص ڊيٽا آهي، يعني ريپليڪشن فيڪٽر کي حساب ۾ رکڻ کان سواءِ).
اهڙيء طرح، BlockCache مجموعي ڊيٽا جي مقدار جو صرف 23٪ آهي ۽ اهو حقيقي حالتن جي بلڪل ويجهو آهي جنهن کي بگ ڊيٽا سڏيو ويندو آهي. ۽ هي اهو آهي جتي مزو شروع ٿئي ٿو - ڇاڪاڻ ته ظاهر آهي، گهٽ ڪيش هٽ، ڪارڪردگي خراب. آخرڪار، جيڪڏهن توهان ياد ڪيو، توهان کي تمام گهڻو ڪم ڪرڻو پوندو - يعني. ڪالنگ سسٽم جي ڪمن تي ھيٺ وڃو. بهرحال، اهو بچي نٿو سگهجي، تنهنڪري اچو ته هڪ مڪمل طور تي مختلف پاسو ڏسو - ڪيش اندر ڊيٽا کي ڇا ٿيندو؟
اچو ته صورتحال کي آسان بڻايون ۽ فرض ڪريو ته اسان وٽ هڪ ڪيش آهي جيڪو صرف 1 اعتراض کي پورو ڪري ٿو. هتي هڪ مثال آهي ته ڇا ٿيندو جڏهن اسان ڪيش کان 3 ڀيرا وڏي ڊيٽا جي مقدار سان ڪم ڪرڻ جي ڪوشش ڪندا، اسان کي ڪرڻو پوندو:
1. بلاڪ 1 کي ڪيش ۾ رکو
2. ڪيش مان بلاڪ 1 هٽايو
3. بلاڪ 2 کي ڪيش ۾ رکو
4. ڪيش مان بلاڪ 2 هٽايو
5. بلاڪ 3 کي ڪيش ۾ رکو
5 عمل مڪمل ٿي ويا! بهرحال، هن صورتحال کي عام نه ٿو چئي سگهجي؛ حقيقت ۾، اسان HBase کي مڪمل طور تي بيڪار ڪم جو هڪ گروپ ڪرڻ تي مجبور ڪري رهيا آهيون. اهو مسلسل OS ڪيش مان ڊيٽا پڙهي ٿو، ان کي BlockCache ۾ رکي ٿو، صرف ان کي فوري طور تي اڇلائڻ لاء ڇاڪاڻ ته ڊيٽا جو هڪ نئون حصو اچي چڪو آهي. پوسٽ جي شروعات ۾ اينيميشن ڏيکاري ٿي مسئلي جو جوهر - ڪچرو ڪليڪٽر پيماني تي وڃي رهيو آهي، ماحول گرم ٿي رهيو آهي، پري ۽ گرم سويڊن ۾ ننڍڙي گريٽا پريشان ٿي رهي آهي. ۽ اسان آئي ٽي ماڻهو واقعي ان کي پسند نه ڪندا آهيون جڏهن ٻار اداس هوندا آهن، تنهنڪري اسان سوچڻ شروع ڪندا آهيون ته اسان ان بابت ڇا ڪري سگهون ٿا.
ڇا جيڪڏهن توهان ڪيش ۾ سڀئي بلاڪ نه رکون، پر انهن مان صرف هڪ خاص سيڪڙو، ته جيئن ڪيش اوور فلو نه ٿئي؟ اچو ته شروع ڪريون صرف ڪوڊ جون چند لائينون شامل ڪندي فنڪشن جي شروعات ۾ 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 وسيلا بچائيندا آهيون صرف ان کي فوري طور تي مارٽن ڪتن جي نالي ۾ اڇلائڻ لاءِ:
ساڳئي وقت، سي پي يو استعمال وڌائي ٿو، پر پيداوار جي ڀيٽ ۾ تمام گهٽ آهي:
اهو پڻ ياد رکڻ جي قابل آهي ته BlockCache ۾ محفوظ ڪيل بلاڪ مختلف آهن. گهڻو ڪري، اٽڪل 95٪، ڊيٽا پاڻ آهي. ۽ باقي ميٽا ڊيٽا آهي، جهڙوڪ بلوم فلٽر يا LEAF_INDEX ۽ . هي ڊيٽا ڪافي ناهي، پر اهو تمام ڪارائتو آهي، ڇاڪاڻ ته ڊيٽا تائين سڌو رسائي حاصل ڪرڻ کان اڳ، HBase اهو سمجهڻ لاءِ ميٽا ڏانهن رخ ڪري ٿو ته ڇا هتي وڌيڪ ڳولها ڪرڻ ضروري آهي ۽، جيڪڏهن ائين آهي، ته واقعي دلچسپي جو بلاڪ ڪٿي آهي.
تنهن ڪري، ڪوڊ ۾ اسان ڏسون ٿا چيڪ حالت buf.getBlockType().isData() ۽ هن ميٽا جي مهرباني، اسان ان کي ڪنهن به صورت ۾ ڪيش ۾ ڇڏينداسين.
ھاڻي اچو ته لوڊ وڌايو ۽ ھڪڙي ھڪڙي ھڪڙي خصوصيت کي ٿورو تنگ ڪريو. پهرين ٽيسٽ ۾ اسان ڪٽ آف فيصد = 20 ڪيو ۽ بلاڪ ڪيچ ٿورڙو استعمال ڪيو ويو. هاڻي اچو ته ان کي 23% تي سيٽ ڪريون ۽ هر 100 منٽن ۾ 5 ٿريڊس شامل ڪري ڏسو ته ڪهڙي نقطي تي سنترپت ٿئي ٿي:
هتي اسان ڏسون ٿا ته اصل نسخو لڳ ڀڳ فوري طور تي ڇت تي اچي ٿو اٽڪل 100 هزار درخواستن في سيڪنڊ تي. جڏهن ته پيچ 300 هزار تائين هڪ تيز رفتار ڏئي ٿو. ساڳئي وقت، اهو واضح آهي ته وڌيڪ تيز رفتار هاڻي ايترو "مفت" ناهي؛ سي پي يو استعمال پڻ وڌي رهيو آهي.
بهرحال، اهو هڪ تمام خوبصورت حل نه آهي، ڇو ته اسان اڳ ۾ نه ڄاڻون ٿا ته بلاڪ جي ڪهڙي سيڪڙو کي ڪيش ڪرڻ جي ضرورت آهي، اهو لوڊ پروفائل تي منحصر آهي. تنهن ڪري، هڪ ميکانيزم تي عمل ڪيو ويو هو خودڪار طريقي سان هن پيٽرولر کي ترتيب ڏيڻ جي عملن جي پڙهڻ جي سرگرمي جي لحاظ سان.
ھن کي ڪنٽرول ڪرڻ لاءِ ٽي آپشن شامل ڪيا ويا آھن:
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 سيڪنڊن ۾ اسين حساب ڪريون ٿا ته ڪيترا بائيٽ هئا فارمولا استعمال ڪندي خارج ڪيو ويو:
اوور هيڊ = آزاد ٿيل بائيٽ جو مجموعو (ايم بي) * 100 / حد (ايم بي) - 100؛
جيڪڏهن حقيقت ۾ 2000 MB ڪڍيا ويا، ته پوءِ اوور هيڊ برابر آهي:
2000 * 100 / 500 - 100 = 300٪
الورورٿمز ڪوشش ڪن ٿا ته ڪجھ ڏهن سيڪڙو کان وڌيڪ نه برقرار رکون، ان ڪري خصوصيت ڪيش ٿيل بلاڪن جو سيڪڙو گھٽائي ٿي، ان ڪري آٽو ٽيوننگ ميڪانيزم لاڳو ڪري ٿي.
بهرحال، جيڪڏهن لوڊ گهٽجي وڃي، اچو ته چئو ته صرف 200 MB بيدخل آهن ۽ اوور هيڊ منفي ٿي وڃي ٿو (نام نهاد اوور شوٽنگ):
200 * 100 / 500 - 100 = -60٪
ان جي برعڪس، خصوصيت وڌندي ويندي ڪيش ٿيل بلاڪ جو سيڪڙو جيستائين اوور هيڊ مثبت نه ٿئي.
هيٺ ڏنل هڪ مثال آهي ته اهو ڪيئن حقيقي ڊيٽا تي نظر اچي ٿو. 0٪ تائين پهچڻ جي ڪوشش ڪرڻ جي ڪا ضرورت ناهي، اهو ناممڪن آهي. اهو تمام سٺو آهي جڏهن اهو اٽڪل 30 - 100٪ آهي، اهو مختصر مدت جي سرجز دوران اصلاح واري موڊ مان وقت کان اڳ نڪرڻ کان بچڻ ۾ مدد ڪري ٿو.
hbase.lru.cache.heavy.eviction.overhead.coefficient - سيٽ ڪري ٿو ته اسان ڪيترو جلدي نتيجو حاصل ڪرڻ چاهيون ٿا. جيڪڏهن اسان پڪ سان ڄاڻون ٿا ته اسان جا پڙهيا گهڻو ڪري ڊگهو آهن ۽ انتظار ڪرڻ نٿا چاهيون، اسان هن تناسب کي وڌائي سگهون ٿا ۽ تيز ڪارڪردگي تيزيء سان حاصل ڪري سگهون ٿا.
مثال طور، اسان هن کوٽائي = 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;
}
اچو ته هاڻي هي سڀ هڪ حقيقي مثال استعمال ڪندي ڏسو. اسان وٽ ھيٺ ڏنل ٽيسٽ اسڪرپٽ آھي:
- اچو ته اسڪين ڪرڻ شروع ڪريون (25 موضوع، بيچ = 100)
- 5 منٽن کان پوء، ملٽي گيٽس شامل ڪريو (25 موضوع، بيچ = 100)
- 5 منٽن کان پوء، ملٽي گيٽس کي بند ڪريو (صرف اسڪين باقي رهي ٿو)
اسان ٻه رنسون ٺاهيندا آهيون، پهريون hbase.lru.cache.heavy.eviction.count.limit = 10000 (جيڪو اصل ۾ خصوصيت کي غير فعال ڪري ٿو)، ۽ پوء مقرر ڪريو حد = 0 (ان کي فعال ڪري ٿو).
هيٺ ڏنل لاگن ۾ اسان ڏسون ٿا ته خصوصيت ڪيئن آن ڪئي وئي آهي ۽ اوور شوٽنگ کي 14-71٪ تي ري سيٽ ڪري ٿو. وقت بوقت لوڊ گھٽجي ٿو، جيڪو Backpressure تي موڙي ٿو ۽ HBase ڪيش وڌيڪ بلاڪ ٻيهر.
لاگ ريجن سرور
بي دخل ڪيو ويو (ايم بي): 0، تناسب 0.0، اوور هيڊ (٪): -100، بھاري بي دخلي انسداد: 0، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 100
بي دخل ڪيو ويو (ايم بي): 0، تناسب 0.0، اوور هيڊ (٪): -100، بھاري بي دخلي انسداد: 0، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 100
بي دخل ڪيو ويو (ايم بي): 2170، تناسب 1.09، اوور هيڊ (٪): 985، بھاري بي دخلي انسداد: 1، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 91 <شروع
بي دخل ڪيو ويو (ايم بي): 3763، تناسب 1.08، اوور هيڊ (٪): 1781، بھاري بي دخلي انسداد: 2، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 76
بي دخل ڪيو ويو (ايم بي): 3306، تناسب 1.07، اوور هيڊ (٪): 1553، بھاري بي دخلي انسداد: 3، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 61
بي دخل ڪيو ويو (ايم بي): 2508، تناسب 1.06، اوور هيڊ (٪): 1154، بھاري بي دخلي انسداد: 4، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 50
بي دخل ڪيو ويو (ايم بي): 1824، تناسب 1.04، اوور هيڊ (٪): 812، بھاري بي دخلي انسداد: 5، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 42
بي دخل ڪيو ويو (ايم بي): 1482، تناسب 1.03، اوور هيڊ (٪): 641، بھاري بي دخلي انسداد: 6، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 36
بي دخل ڪيو ويو (ايم بي): 1140، تناسب 1.01، اوور هيڊ (٪): 470، بھاري بي دخلي انسداد: 7، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 32
بي دخل ڪيو ويو (ايم بي): 913، تناسب 1.0، اوور هيڊ (٪): 356، بھاري بي دخلي انسداد: 8، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 29
بي دخل ڪيو ويو (ايم بي): 912، تناسب 0.89، اوور هيڊ (٪): 356، بھاري بي دخلي انسداد: 9، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 26
بي دخل ڪيو ويو (ايم بي): 684، تناسب 0.76، اوور هيڊ (٪): 242، بھاري بي دخلي انسداد: 10، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 24
بي دخل ڪيو ويو (ايم بي): 684، تناسب 0.61، اوور هيڊ (٪): 242، بھاري بي دخلي انسداد: 11، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 456، تناسب 0.51، اوور هيڊ (٪): 128، بھاري بي دخلي انسداد: 12، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 21
بي دخل ڪيو ويو (ايم بي): 456، تناسب 0.42، اوور هيڊ (٪): 128، بھاري بي دخلي انسداد: 13، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 20
بي دخل ڪيو ويو (ايم بي): 456، تناسب 0.33، اوور هيڊ (٪): 128، بھاري بي دخلي انسداد: 14، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 15، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.32، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 16، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.31، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 17، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.3، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 18، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.29، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 19، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.27، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 20، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.25، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 21، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.24، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 22، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.22، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 23، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.21، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 24، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.2، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 25، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.17، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 26، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 456، تناسب 0.17، اوور هيڊ (٪): 128، بھاري بي دخلي انسداد: 27، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18 < شامل ڪيو ويو (پر ٽيبل ساڳيو)
بي دخل ڪيو ويو (ايم بي): 456، تناسب 0.15، اوور هيڊ (٪): 128، بھاري بي دخلي انسداد: 28، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.13، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 29، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.11، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 30، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.09، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 31، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.08، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 32، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.07، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 33، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.06، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 34، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.05، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 35، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.05، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 36، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.04، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 37، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 109، تناسب 0.04، اوور هيڊ (٪): -46، بھاري بي دخلي انسداد: 37، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22 < پوئتي دٻاء
بي دخل ڪيو ويو (ايم بي): 798، تناسب 0.24، اوور هيڊ (٪): 299، بھاري بي دخلي انسداد: 38، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 20
بي دخل ڪيو ويو (ايم بي): 798، تناسب 0.29، اوور هيڊ (٪): 299، بھاري بي دخلي انسداد: 39، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18
بي دخل ڪيو ويو (ايم بي): 570، تناسب 0.27، اوور هيڊ (٪): 185، بھاري بي دخلي انسداد: 40، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 17
بي دخل ڪيو ويو (ايم بي): 456، تناسب 0.22، اوور هيڊ (٪): 128، بھاري بي دخلي انسداد: 41، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 16
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.16، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 42، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 16
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.11، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 43، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 16
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.09، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 44، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 16
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.07، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 45، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 16
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.05، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 46، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 16
بي دخل ڪيو ويو (ايم بي): 222، تناسب 0.04، اوور هيڊ (٪): 11، بھاري بي دخلي انسداد: 47، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 16
بي دخل ڪيو ويو (ايم بي): 104، تناسب 0.03، اوور هيڊ (٪): -48، ڳري بي دخلي انسداد: 47، موجوده ڪيشنگ DataBlock (٪): 21 < interrupt gets
بي دخل ڪيو ويو (ايم بي): 684، تناسب 0.2، اوور هيڊ (٪): 242، بھاري بي دخلي انسداد: 48، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 19
بي دخل ڪيو ويو (ايم بي): 570، تناسب 0.23، اوور هيڊ (٪): 185، بھاري بي دخلي انسداد: 49، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.22، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 50، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.21، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 51، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.2، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 52، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.18، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 53، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.16، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 54، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18
بي دخل ڪيو ويو (ايم بي): 228، تناسب 0.14، اوور هيڊ (٪): 14، بھاري بي دخلي انسداد: 55، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 18
بي دخل ڪيو ويو (ايم بي): 112، تناسب 0.14، اوور هيڊ (٪): -44، بھاري بي دخلي انسداد: 55، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 23 < پوئتي دٻاء
بي دخل ڪيو ويو (ايم بي): 456، تناسب 0.26، اوور هيڊ (٪): 128، بھاري بي دخلي انسداد: 56، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.31، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 57، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 58، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 59، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 60، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 61، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 62، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 63، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.32، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 64، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 65، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 66، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.32، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 67، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 68، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.32، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 69، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.32، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 70، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 71، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 72، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 73، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 74، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 75، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 342، تناسب 0.33، اوور هيڊ (٪): 71، بھاري بي دخلي انسداد: 76، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 22
بي دخل ڪيو ويو (ايم بي): 21، تناسب 0.33، اوور هيڊ (٪): -90، بھاري بي دخلي انسداد: 76، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 32
بي دخل ڪيو ويو (ايم بي): 0، تناسب 0.0، اوور هيڊ (٪): -100، بھاري بي دخلي انسداد: 0، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 100
بي دخل ڪيو ويو (ايم بي): 0، تناسب 0.0، اوور هيڊ (٪): -100، بھاري بي دخلي انسداد: 0، موجوده ڪيشنگ ڊيٽا بلاڪ (٪): 100
ساڳئي عمل کي ٻن ڪيش حصن جي وچ ۾ لاڳاپن جي گراف جي صورت ۾ ڏيکارڻ لاءِ اسڪين جي ضرورت هئي - اڪيلو (جتي بلاڪ جيڪي اڳ ۾ ڪڏهن به درخواست نه ڪيا ويا آهن) ۽ ملٽي (ڊيٽا "درخواست ڪئي وئي" گهٽ ۾ گهٽ هڪ ڀيرو هتي ذخيرو ٿيل آهي):
۽ آخرڪار، پيرا ميٽرز جي آپريشن کي گراف جي صورت ۾ ڇا نظر اچي ٿو. مقابلي لاءِ، ڪيش کي شروع ۾ مڪمل طور تي بند ڪيو ويو، پوءِ HBase کي ڪيشنگ سان شروع ڪيو ويو ۽ 5 منٽ (30 خارج ڪرڻ واري چڪر) جي اصلاح واري ڪم جي شروعات کي دير ڪرڻ سان.
مڪمل ڪوڊ ڳولي سگھجي ٿو پل جي درخواست ۾ github تي.
بهرحال، في سيڪنڊ 300 هزار پڙهڻ اهو سڀ ڪجهه نه آهي جيڪو هن هارڊويئر تي حاصل ڪري سگهجي ٿو انهن حالتن هيٺ. حقيقت اها آهي ته جڏهن توهان کي HDFS ذريعي ڊيٽا تائين رسائي جي ضرورت آهي، ShortCircuitCache (هتي 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 - گرافڪس تائين). عمودي محور تيز رفتار کي ڏيکاري ٿو جيڪو صرف هڪ ڪيش هجڻ جي صورت ۾ ايس ايس سي جي نسبت ۾ واڌ جو نتيجو آهي.
گراف کي ڪيئن پڙهو: هڪ ڪيش سان 100 KB بلاڪ ۾ 64 هزار پڙهڻ لاءِ عمل جو وقت 78 سيڪنڊن جي ضرورت آهي. جڏهن ته 5 ڪيچز سان اهو 16 سيڪنڊن جو وقت وٺندو آهي. اهي. اتي ~ 5 ڀيرا جي هڪ acceleration آهي. جيئن گراف مان ڏسي سگهجي ٿو، اهو اثر ٿورڙي تعداد ۾ متوازي پڙهڻ لاءِ تمام گهڻو قابل ذڪر نه آهي؛ اهو هڪ قابل ذڪر ڪردار ادا ڪرڻ شروع ڪري ٿو جڏهن 50 کان وڌيڪ ٿريڊ پڙهيا وڃن. اهو پڻ قابل ذڪر آهي ته 6 مان SSCs جو تعداد وڌايو وڃي. ۽ مٿي هڪ خاص طور تي ننڍي ڪارڪردگي وڌائي ٿو.
نوٽ 1: جيئن ته امتحان جا نتيجا ڪافي غير مستحڪم آهن (هيٺ ڏسو)، 3 رنسون ڪيا ويا ۽ نتيجن جي قيمتن کي اوسط ڪيو ويو.
نوٽ 2: بي ترتيب رسائي کي ترتيب ڏيڻ کان ڪارڪردگي حاصل ڪرڻ ساڳيو آهي، جيتوڻيڪ رسائي پاڻ کي ٿورڙي سست آهي.
بهرحال، اهو واضح ڪرڻ ضروري آهي ته، HBase سان ڪيس جي برعڪس، هي رفتار هميشه مفت ناهي. هتي اسان سي پي يو جي وڌيڪ ڪم ڪرڻ جي صلاحيت کي ”ان لاڪ“ ڪريون ٿا، بجاءِ لاڪ تي لٽڪڻ جي.
هتي توهان مشاهدو ڪري سگهو ٿا ته، عام طور تي، ڪيچ جي تعداد ۾ اضافو CPU استعمال ۾ تقريبن متناسب اضافو ڏئي ٿو. بهرحال، ٿورڙو وڌيڪ کٽڻ وارا مجموعا آهن.
مثال طور، اچو ته سيٽنگ تي هڪ ويجهي نظر رکون SSC = 3. حد تي ڪارڪردگي ۾ اضافو تقريبا 3.3 ڀيرا آهي. ھيٺ ڏنل آھن نتيجا سڀني ٽن جدا جدا رنن مان.
جڏهن ته سي پي يو جو استعمال اٽڪل 2.8 ڀيرا وڌي ٿو. فرق تمام وڏو نه آهي، پر ننڍڙي گريتا اڳ ۾ ئي خوش آهي ۽ شايد اسڪول ۾ وڃڻ ۽ سبق وٺڻ جو وقت هجي.
اهڙيء طرح، اهو ڪنهن به اوزار لاء مثبت اثر ٿيندو جيڪو استعمال ڪري ٿو بلڪ رسائي کي HDFS تائين (مثال طور اسپارڪ، وغيره)، بشرطيڪ ايپليڪيشن ڪوڊ ہلڪو وزن هجي (يعني پلگ HDFS ڪلائنٽ جي پاسي تي آهي) ۽ مفت سي پي يو پاور آهي. . چيڪ ڪرڻ لاءِ، اچو ته جانچ ڪريون ته HBase کان پڙهڻ لاءِ BlockCache Optimization ۽ SSC ٽيوننگ جي گڏيل استعمال جو ڪهڙو اثر پوندو.
اهو ڏسي سگھجي ٿو ته اهڙين حالتن ۾ اهو اثر ايترو وڏو ناهي جيترو بهتر ٽيسٽن ۾ (پڙهڻ بغير ڪنهن پروسيسنگ جي)، پر اهو ممڪن آهي ته هتي اضافي 80K کي نچوض ڪيو وڃي. گڏو گڏ، ٻنهي اصلاحن کي 4x اسپيڊ اپ تائين مهيا ڪن ٿا.
انهي اصلاح لاءِ هڪ پي آر پڻ ٺاهيو ويو ، جنهن کي ضم ڪيو ويو آهي ۽ هي ڪارڪردگي مستقبل جي رليز ۾ موجود هوندي.
۽ آخرڪار، اهو دلچسپ هو ته پڙهڻ جي ڪارڪردگي جي مقابلي ۾ ساڳئي وسيع ڪالمن ڊيٽابيس، Cassandra ۽ HBase.
هن کي ڪرڻ لاءِ، اسان شروع ڪيو معياري YCSB لوڊ ٽيسٽنگ يوٽيلٽي جا مثال ٻن ميزبانن (مجموعي طور تي 800 موضوع). سرور جي پاسي - 4 ميزبانن تي ريجن سرور ۽ ڪئاسندرا جا 4 مثال (نه اهي جتي ڪلائنٽ هلائي رهيا آهن، انهن جي اثر کان بچڻ لاءِ). پڙهڻ جي ماپ جي جدولن مان آيا:
HBase - 300 GB HDFS تي (100 GB خالص ڊيٽا)
Cassandra - 250 GB (نقل فيڪٽر = 3)
اهي. حجم تقريبن ساڳيو هو (HBase ۾ ٿورو وڌيڪ).
HBase parameters:
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 لاگز تجزيا ڪيا ويا ۽ ايڪسل گرافس ۾ مرتب ڪيا ويا:
جئين توهان ڏسي سگهو ٿا، اهي اصلاحون انهن حالتن جي تحت انهن ڊيٽابيس جي ڪارڪردگي جو مقابلو ڪرڻ ۽ في سيڪنڊ 450 هزار پڙهڻ حاصل ڪرڻ ممڪن بڻائي ٿي.
اسان کي اميد آهي ته هي معلومات پيداوار لاء دلچسپ جدوجهد دوران ڪنهن لاء ڪارائتو ٿي سگهي ٿي.
جو ذريعو: www.habr.com