பெரிய தரவுகளுடன் பணிபுரியும் போது உயர் செயல்திறன் முக்கிய தேவைகளில் ஒன்றாகும். Sberbank இல் உள்ள தரவு ஏற்றுதல் பிரிவில், கிட்டத்தட்ட எல்லா பரிவர்த்தனைகளையும் எங்கள் Hadoop-அடிப்படையிலான Data Cloudக்குள் செலுத்துகிறோம், எனவே பெரிய அளவிலான தகவல்களைக் கையாளுகிறோம். இயற்கையாகவே, செயல்திறனை மேம்படுத்துவதற்கான வழிகளை நாங்கள் எப்பொழுதும் தேடுகிறோம், இப்போது 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 மடங்கு அதிகமாக “கேஸ்” என்று படிக்கும். , அதாவது எங்கள் விஷயத்தில் 256 KB. ஏனென்றால், இந்த நடத்தையைத் தடுக்க FADV_RANDOM கொடியை அமைப்பதற்கான எளிதான வழி ஜாவாவிடம் இல்லை.
இதன் விளைவாக, எங்கள் 100 பைட்டுகளைப் பெற, 2600 மடங்கு அதிகமாகப் படிக்கப்படுகிறது. ப்ளாக் அளவை ஒரு கிலோபைட்டாகக் குறைத்து, குறிப்பிட்ட கொடியை அமைத்து, பெரிய ஞான முடுக்கம் பெறுவோம், தீர்வு தெளிவாகத் தெரிகிறது. ஆனால் சிக்கல் என்னவென்றால், தொகுதி அளவை 2 மடங்கு குறைப்பதன் மூலம், ஒரு யூனிட் நேரத்திற்கு படிக்கும் பைட்டுகளின் எண்ணிக்கையையும் 2 மடங்கு குறைக்கிறோம்.
FADV_RANDOM கொடியை அமைப்பதன் மூலம் சில ஆதாயங்களைப் பெற முடியும், ஆனால் உயர் மல்டி த்ரெடிங் மற்றும் 128 KB தொகுதி அளவுடன் மட்டுமே பெற முடியும், ஆனால் இது அதிகபட்சம் இரண்டு பத்து சதவிகிதம் ஆகும்:
100 கோப்புகளில் சோதனைகள் மேற்கொள்ளப்பட்டன, ஒவ்வொன்றும் 1 ஜிபி அளவு மற்றும் 10 HDDகளில் அமைந்துள்ளது.
கொள்கையளவில், இந்த வேகத்தில் நாம் எதை நம்பலாம் என்பதைக் கணக்கிடுவோம்:
10 MB/sec வேகத்தில் 280 வட்டுகளில் இருந்து படித்ததாக வைத்துக்கொள்வோம், அதாவது. 3 மில்லியன் முறை 100 பைட்டுகள். ஆனால் நாம் நினைவில் வைத்திருப்பது போல, நமக்குத் தேவையான தரவு, படித்ததை விட 2600 மடங்கு குறைவாக உள்ளது. இவ்வாறு, 3 மில்லியனை 2600 ஆல் வகுத்து பெறுகிறோம் வினாடிக்கு 1100 பதிவுகள்.
மனச்சோர்வு, இல்லையா? அதுதான் இயல்பு சீரற்ற அணுகல் HDD இல் தரவுக்கான அணுகல் - தொகுதி அளவைப் பொருட்படுத்தாமல். இது சீரற்ற அணுகலின் இயற்பியல் வரம்பு மற்றும் இதுபோன்ற நிலைமைகளின் கீழ் எந்த தரவுத்தளமும் அதிகமாக அழுத்த முடியாது.
தரவுத்தளங்கள் எவ்வாறு அதிக வேகத்தை அடைகின்றன? இந்த கேள்விக்கு பதிலளிக்க, பின்வரும் படத்தில் என்ன நடக்கிறது என்பதைப் பார்ப்போம்:
முதல் சில நிமிடங்களுக்கு வேகம் உண்மையில் ஒரு வினாடிக்கு ஆயிரம் பதிவுகள் என்பதை இங்கே காண்கிறோம். இருப்பினும், மேலும், கோரப்பட்டதை விட அதிகமாகப் படிக்கப்படுவதால், தரவு இயக்க முறைமையின் (லினக்ஸ்) பஃப் / கேச் இல் முடிவடைகிறது மற்றும் வேகம் வினாடிக்கு 60 ஆயிரமாக அதிகரிக்கிறது.
எனவே, OS தற்காலிக சேமிப்பில் உள்ள அல்லது ஒப்பிடக்கூடிய அணுகல் வேகத்தில் SSD/NVMe சேமிப்பக சாதனங்களில் உள்ள தரவை மட்டுமே அணுகலை துரிதப்படுத்துவோம்.
எங்கள் விஷயத்தில், நாங்கள் 4 சேவையகங்களின் பெஞ்சில் சோதனைகளை நடத்துவோம், ஒவ்வொன்றும் பின்வருமாறு கட்டணம் விதிக்கப்படும்:
CPU: 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 MB அளவு, FAST_DIFF ஆல் சுருக்கப்பட்டது, அதாவது. மொத்தம் 410 ஜிபி (இது தூய தரவு, அதாவது பிரதி காரணியை கணக்கில் எடுத்துக் கொள்ளாமல்).
எனவே, BlockCache ஆனது மொத்த தரவு அளவின் 23% மட்டுமே ஆகும், மேலும் இது BigData எனப்படும் உண்மையான நிலைமைகளுக்கு மிகவும் நெருக்கமாக உள்ளது. இங்குதான் வேடிக்கை தொடங்குகிறது - ஏனென்றால், குறைவான கேச் ஹிட்கள், செயல்திறன் மோசமாக இருக்கும். எல்லாவற்றிற்கும் மேலாக, நீங்கள் தவறவிட்டால், நீங்கள் நிறைய வேலை செய்ய வேண்டியிருக்கும் - அதாவது. அழைப்பு அமைப்பு செயல்பாடுகளுக்குச் செல்லவும். இருப்பினும், இதைத் தவிர்க்க முடியாது, எனவே முற்றிலும் மாறுபட்ட அம்சத்தைப் பார்ப்போம் - தற்காலிக சேமிப்பில் உள்ள தரவுகளுக்கு என்ன நடக்கும்?
நிலைமையை எளிமையாக்கி, 1 பொருளுக்கு மட்டுமே பொருந்தக்கூடிய தற்காலிக சேமிப்பு உள்ளது என்று வைத்துக்கொள்வோம். தற்காலிக சேமிப்பை விட 3 மடங்கு பெரிய டேட்டா வால்யூமுடன் வேலை செய்ய முயலும்போது என்ன நடக்கும் என்பதற்கான உதாரணம் இங்கே உள்ளது, நாம் செய்ய வேண்டியது:
1. தொகுதி 1 ஐ தற்காலிக சேமிப்பில் வைக்கவும்
2. தற்காலிக சேமிப்பிலிருந்து தொகுதி 1 ஐ அகற்றவும்
3. தொகுதி 2 ஐ தற்காலிக சேமிப்பில் வைக்கவும்
4. தற்காலிக சேமிப்பிலிருந்து தொகுதி 2 ஐ அகற்றவும்
5. தொகுதி 3 ஐ தற்காலிக சேமிப்பில் வைக்கவும்
5 செயல்கள் முடிந்தது! இருப்பினும், இந்த சூழ்நிலையை சாதாரணமாக அழைக்க முடியாது; உண்மையில், முற்றிலும் பயனற்ற வேலையைச் செய்ய நாங்கள் HBase ஐ கட்டாயப்படுத்துகிறோம். இது தொடர்ந்து OS தற்காலிக சேமிப்பிலிருந்து தரவைப் படிக்கிறது, அதை BlockCache இல் வைக்கிறது, தரவுகளின் புதிய பகுதி வந்துள்ளதால் உடனடியாக அதை வெளியேற்றும். இடுகையின் தொடக்கத்தில் உள்ள அனிமேஷன் பிரச்சனையின் சாராம்சத்தைக் காட்டுகிறது - குப்பை சேகரிப்பு அளவு குறைகிறது, வளிமண்டலம் வெப்பமடைகிறது, தொலைதூர மற்றும் சூடான ஸ்வீடனில் உள்ள சிறிய கிரேட்டா வருத்தப்படுகிறார். குழந்தைகள் சோகமாக இருக்கும் போது 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 ஐ அமைத்து என்ன நடக்கிறது என்பதைப் பார்க்கவும்:
விளைவு வெளிப்படையானது. கீழேயுள்ள வரைபடங்களில், ஏன் இத்தகைய முடுக்கம் ஏற்பட்டது என்பது தெளிவாகிறது - செவ்வாய் கிரக நாய்களின் வடிகாலில் உடனடியாகத் தூக்கி எறிவதற்காக மட்டுமே டேட்டாவை தற்காலிக சேமிப்பில் வைக்கும் சிசிபியன் வேலையைச் செய்யாமல் நிறைய ஜிசி வளங்களைச் சேமிக்கிறோம்:
அதே நேரத்தில், CPU பயன்பாடு அதிகரிக்கிறது, ஆனால் உற்பத்தித்திறனை விட மிகவும் குறைவாக உள்ளது:
BlockCache இல் சேமிக்கப்பட்ட தொகுதிகள் வேறுபட்டவை என்பதும் குறிப்பிடத்தக்கது. பெரும்பாலான, சுமார் 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 எம்பி அமைப்பது உகந்ததாகும். நடுத்தர வர்க்கத்திற்கு (~10 கோர்கள்) 200-300 எம்பி. பலவீனமான அமைப்புகளுக்கு (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 எம்பி மட்டுமே வெளியேற்றப்பட்டு, மேல்நிலை எதிர்மறையாகிறது (ஓவர்ஷூட்டிங் என அழைக்கப்படுவது):
200 * 100 / 500 - 100 = -60%
மாறாக, ஓவர்ஹெட் பாசிட்டிவ் ஆகும் வரை இந்த அம்சம் தற்காலிக சேமிப்பு தொகுதிகளின் சதவீதத்தை அதிகரிக்கும்.
உண்மையான தரவுகளில் இது எப்படி இருக்கும் என்பதற்கான எடுத்துக்காட்டு கீழே உள்ளது. 0% ஐ அடைய முயற்சிக்க வேண்டிய அவசியமில்லை, அது சாத்தியமற்றது. இது சுமார் 30 - 100% ஆக இருக்கும்போது மிகவும் நல்லது, இது குறுகிய கால எழுச்சிகளின் போது தேர்வுமுறை பயன்முறையிலிருந்து முன்கூட்டியே வெளியேறுவதைத் தவிர்க்க உதவுகிறது.
hbase.lru.cache.heavy.eviction.overhead.coficiency - எவ்வளவு விரைவாக முடிவைப் பெற விரும்புகிறோம் என்பதை அமைக்கிறது. எங்கள் வாசிப்புகள் பெரும்பாலும் நீளமானவை மற்றும் காத்திருக்க விரும்பவில்லை என்பதை உறுதியாக அறிந்தால், இந்த விகிதத்தை அதிகரித்து, அதிக செயல்திறனை விரைவாகப் பெறலாம்.
எடுத்துக்காட்டாக, இந்த குணகம் = 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 தற்காலிக சேமிப்புகளை மீண்டும் இயக்குகிறது.
Log 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 ஜிபி (பிரதி காரணி = 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 பதிவுகள் பாகுபடுத்தப்பட்டு எக்செல் வரைபடங்களாக தொகுக்கப்பட்டன:
நீங்கள் பார்க்க முடியும் என, இந்த மேம்படுத்தல்கள் இந்த நிலைமைகளின் கீழ் இந்த தரவுத்தளங்களின் செயல்திறனை ஒப்பிட்டு ஒரு வினாடிக்கு 450 ஆயிரம் வாசிப்புகளை அடைவதை சாத்தியமாக்குகின்றன.
உற்பத்தித்திறனுக்கான உற்சாகமான போராட்டத்தின் போது இந்தத் தகவல் ஒருவருக்கு பயனுள்ளதாக இருக்கும் என்று நம்புகிறோம்.
ஆதாரம்: www.habr.com