Bioyino - விநியோகிக்கப்பட்ட, அளவிடக்கூடிய அளவீடுகள் திரட்டி

எனவே நீங்கள் அளவீடுகளை சேகரிக்கிறீர்கள். நாம் இருக்கிறோம். அளவீடுகளையும் சேகரிக்கிறோம். நிச்சயமாக, வணிகத்திற்கு அவசியம். இன்று நாம் எங்கள் கண்காணிப்பு அமைப்பின் முதல் இணைப்பைப் பற்றி பேசுவோம் - ஒரு statsd-இணக்கமான திரட்டல் சேவையகம் பயோயினோ, ஏன் அதை எழுதினோம், ஏன் ப்ரூபெக்கை கைவிட்டோம்.

எங்கள் முந்தைய கட்டுரைகளிலிருந்து (1, 2) சில காலம் வரை நாங்கள் பயன்படுத்தி மதிப்பெண்களை சேகரித்தோம் என்பதை நீங்கள் கண்டுபிடிக்கலாம் புரூபெக். இது C இல் எழுதப்பட்டுள்ளது. ஒரு குறியீட்டுப் பார்வையில், இது ஒரு பிளக்கைப் போல எளிமையானது (நீங்கள் பங்களிக்க விரும்பும் போது இது முக்கியமானது) மேலும், மிக முக்கியமாக, இது உச்சநிலையில் வினாடிக்கு 2 மில்லியன் அளவீடுகளை (MPS) கையாளுகிறது. எந்த பிரச்சனையும் இல்லாமல். 4 மில்லியன் MPSக்கான ஆதரவை நட்சத்திரக் குறியுடன் ஆவணப்படுத்துகிறது. இதன் பொருள் நீங்கள் லினக்ஸில் பிணையத்தை சரியாக உள்ளமைத்தால், குறிப்பிட்ட எண்ணிக்கையைப் பெறுவீர்கள். (நெட்வொர்க்கை அப்படியே விட்டால் எத்தனை எம்.பி.எஸ்.களைப் பெற முடியும் என்பது எங்களுக்குத் தெரியாது). இந்த நன்மைகள் இருந்தபோதிலும், ப்ரூபெக் பற்றி எங்களுக்கு பல கடுமையான புகார்கள் இருந்தன.

உரிமைகோரல் 1. திட்டத்தின் டெவெலப்பரான கிதுப், அதை ஆதரிப்பதை நிறுத்தினார்: இணைப்புகள் மற்றும் திருத்தங்களை வெளியிடுதல், எங்களுடையது மற்றும் (நம்முடையது மட்டுமல்ல) PR ஆகியவற்றை ஏற்றுக்கொள்வது. கடந்த சில மாதங்களில் (பிப்ரவரி-மார்ச் 2018 முதல் எங்காவது), செயல்பாடு மீண்டும் தொடங்கியது, ஆனால் அதற்கு முன் கிட்டத்தட்ட 2 ஆண்டுகள் முழுமையான அமைதி இருந்தது. கூடுதலாக, திட்டம் உருவாக்கப்படுகிறது உள் Ghub தேவைகளுக்கு, இது புதிய அம்சங்களை அறிமுகப்படுத்துவதற்கு கடுமையான தடையாக மாறும்.

உரிமைகோரல் 2. கணக்கீடுகளின் துல்லியம். ப்ரூபெக் மொத்தமாக 65536 மதிப்புகளை திரட்டுகிறார். எங்கள் விஷயத்தில், சில அளவீடுகளுக்கு, திரட்டல் காலத்தில் (30 வினாடிகள்), அதிக மதிப்புகள் வரக்கூடும் (உச்சத்தில் 1). இந்த மாதிரியின் விளைவாக, அதிகபட்ச மற்றும் குறைந்தபட்ச மதிப்புகள் பயனற்றதாகத் தோன்றும். உதாரணமாக, இது போன்றது:

அப்படியே இருந்தது

எப்படி இருந்திருக்க வேண்டும்

அதே காரணத்திற்காக, தொகைகள் பொதுவாக தவறாகக் கணக்கிடப்படுகின்றன. 32-பிட் ஃப்ளோட் ஓவர்ஃப்ளோவுடன் ஒரு பிழையைச் சேர்க்கவும், இது பொதுவாக ஒரு அப்பாவி மெட்ரிக்கைப் பெறும்போது சேவையகத்தை segfault க்கு அனுப்புகிறது, மேலும் எல்லாமே சிறப்பாக மாறும். பிழை, மூலம், சரி செய்யப்படவில்லை.

இறுதியாக, X. எழுதும் நேரத்தில், எங்களால் கண்டுபிடிக்க முடிந்த 14 அதிகமாகவோ அல்லது குறைவாகவோ செயல்படும் statsd செயலாக்கங்களுக்கு அதை வழங்கத் தயாராக உள்ளோம். 4 மில்லியன் MPSஐ ஏற்றுக்கொள்வது போதாது என்று சில ஒற்றை உள்கட்டமைப்புகள் வளர்ந்துள்ளன என்று கற்பனை செய்து கொள்வோம். அல்லது அது இன்னும் வளரவில்லை என்றாலும், அளவீடுகள் ஏற்கனவே உங்களுக்கு மிகவும் முக்கியமானவை, விளக்கப்படங்களில் குறுகிய, 2-3 நிமிட டிப்ஸ் கூட ஏற்கனவே முக்கியமானதாகி, மேலாளர்களிடையே தீர்க்கமுடியாத மனச்சோர்வை ஏற்படுத்தும். மனச்சோர்வுக்கு சிகிச்சையளிப்பது நன்றியற்ற பணி என்பதால், தொழில்நுட்ப தீர்வுகள் தேவை.

முதலாவதாக, தவறு சகிப்புத்தன்மை, இதனால் சர்வரில் ஏற்படும் திடீர் பிரச்சனை அலுவலகத்தில் மனநோய் ஜாம்பி அபோகாலிப்ஸை ஏற்படுத்தாது. இரண்டாவதாக, லினக்ஸ் நெட்வொர்க் ஸ்டேக்கில் ஆழமாகத் தோண்டாமல், தேவையான அளவுக்கு "அகலத்தில்" அமைதியாக வளராமல், 4 மில்லியனுக்கும் அதிகமான MPS ஐ ஏற்றுக்கொள்ளும் வகையில் அளவிடுதல்.

எங்களிடம் அளவிடுதலுக்கான இடம் இருப்பதால், தவறு சகிப்புத்தன்மையுடன் தொடங்க முடிவு செய்தோம். "பற்றி! தவறு சகிப்புத்தன்மை! இது எளிமையானது, நாங்கள் அதைச் செய்யலாம், ”என்று நாங்கள் நினைத்து 2 சேவையகங்களைத் தொடங்கினோம், ஒவ்வொன்றிலும் ப்ரூபெக்கின் நகலை உயர்த்தினோம். இதைச் செய்ய, நாங்கள் இரண்டு சேவையகங்களுக்கும் அளவீடுகளுடன் போக்குவரத்தை நகலெடுக்க வேண்டியிருந்தது மற்றும் இதற்காக எழுத வேண்டியிருந்தது சிறிய பயன்பாடு. தவறு சகிப்புத்தன்மை பிரச்சனையை நாங்கள் இதனுடன் தீர்த்தோம், ஆனால்... நன்றாக இல்லை. முதலில் எல்லாம் நன்றாகத் தோன்றியது: ஒவ்வொரு ப்ரூபெக்கும் அதன் சொந்த சேகரிப்பு பதிப்பை சேகரிக்கிறது, ஒவ்வொரு 30 வினாடிகளுக்கும் ஒரு முறை கிராஃபைட்டுக்கு தரவை எழுதுகிறது, பழைய இடைவெளியை மேலெழுதுகிறது (இது கிராஃபைட் பக்கத்தில் செய்யப்படுகிறது). ஒரு சேவையகம் திடீரென செயலிழந்தால், எங்களிடம் எப்போதும் ஒருங்கிணைக்கப்பட்ட தரவின் சொந்த நகலுடன் இரண்டாவது சேவை இருக்கும். ஆனால் இங்கே சிக்கல் உள்ளது: சேவையகம் தோல்வியுற்றால், வரைபடத்தில் ஒரு "பார்" தோன்றும். ப்ரூபெக்கின் 30-வினாடி இடைவெளிகள் ஒத்திசைக்கப்படாதது மற்றும் செயலிழக்கும் தருணத்தில் அவற்றில் ஒன்று மேலெழுதப்படவில்லை என்பதே இதற்குக் காரணம். இரண்டாவது சேவையகம் தொடங்கும் போது, ​​அதே விஷயம் நடக்கும். மிகவும் சகிப்புத்தன்மை, ஆனால் நான் சிறப்பாக விரும்புகிறேன்! அளவிடுதல் பிரச்சனையும் நீங்கவில்லை. எல்லா அளவீடுகளும் இன்னும் ஒரு சேவையகத்திற்கு "பறக்க", எனவே நாங்கள் பிணைய அளவைப் பொறுத்து அதே 2-4 மில்லியன் MPS க்கு வரம்பிடப்பட்டுள்ளோம்.

நீங்கள் சிக்கலைப் பற்றி கொஞ்சம் யோசித்து, அதே நேரத்தில் ஒரு மண்வெட்டியுடன் பனியைத் தோண்டினால், பின்வரும் தெளிவான யோசனை நினைவுக்கு வரலாம்: விநியோகிக்கப்பட்ட பயன்முறையில் வேலை செய்யக்கூடிய ஒரு statsd உங்களுக்குத் தேவை. அதாவது, நேரம் மற்றும் அளவீடுகளில் முனைகளுக்கு இடையில் ஒத்திசைவைச் செயல்படுத்தும் ஒன்று. "நிச்சயமாக, அத்தகைய தீர்வு ஏற்கனவே உள்ளது," என்று நாங்கள் கூகிளுக்குச் சென்றோம். மேலும் அவர்கள் எதையும் காணவில்லை. வெவ்வேறு புள்ளிவிவரங்களுக்கான ஆவணங்களைச் சென்ற பிறகு (https://github.com/etsy/statsd/wiki#server-implementations டிசம்பர் 11.12.2017, XNUMX வரை), நாங்கள் எதையும் கண்டுபிடிக்கவில்லை. வெளிப்படையாக, இந்த தீர்வுகளின் டெவலப்பர்கள் அல்லது பயனர்கள் இதுவரை பல அளவீடுகளை சந்திக்கவில்லை, இல்லையெனில் அவர்கள் நிச்சயமாக ஏதாவது கொண்டு வருவார்கள்.

ஜஸ்ட் ஃபார் ஃபன் ஹேக்கத்தானில் எழுதப்பட்ட “பொம்மை” ஸ்டேட்ஸ்டி - பயோயினோவைப் பற்றி நாங்கள் நினைவில் வைத்தோம் (திட்டத்தின் பெயர் ஹேக்கத்தான் தொடங்குவதற்கு முன்பு ஸ்கிரிப்ட் மூலம் உருவாக்கப்பட்டது) மற்றும் எங்களுக்கு அவசரமாக எங்கள் சொந்த புள்ளிவிவரங்கள் தேவை என்பதை உணர்ந்தோம். எதற்காக?

• ஏனெனில் உலகில் மிகக் குறைவான statsd குளோன்கள் உள்ளன,
• ஏனெனில் விரும்பிய அல்லது விரும்பிய தவறு சகிப்புத்தன்மை மற்றும் அளவிடுதல் (சேவையகங்களுக்கு இடையே ஒருங்கிணைந்த அளவீடுகளை ஒத்திசைத்தல் மற்றும் முரண்பாடுகளை அனுப்புவதில் உள்ள சிக்கலைத் தீர்ப்பது உட்பட) வழங்க முடியும்.
• ஏனெனில் ப்ரூபெக்கை விட அளவீடுகளை துல்லியமாக கணக்கிட முடியும்,
• ஏனென்றால், ப்ரூபெக் நடைமுறையில் எங்களுக்கு வழங்காத விரிவான புள்ளிவிவரங்களை நீங்களே சேகரிக்கலாம்,
• ஏனென்றால் எனது சொந்த உயர் செயல்திறன் விநியோகிக்கப்பட்ட அளவிலான ஆய்வக பயன்பாட்டை நிரல்படுத்த எனக்கு ஒரு வாய்ப்பு கிடைத்தது, இது மற்றொரு ஒத்த ஹைப்பர் ஃபார் கட்டமைப்பை முழுமையாக மீண்டும் செய்யாது... சரி, அவ்வளவுதான்.

எதை எழுதுவது? நிச்சயமாக, ரஸ்டில். ஏன்?

• ஏனெனில் ஏற்கனவே ஒரு முன்மாதிரி தீர்வு இருந்தது,
• கட்டுரையின் ஆசிரியர் அந்த நேரத்தில் ரஸ்ட்டை ஏற்கனவே அறிந்திருந்தார், மேலும் அதை திறந்த மூலத்தில் வைக்கும் வாய்ப்போடு தயாரிப்பிற்காக அதில் ஏதாவது எழுத ஆர்வமாக இருந்தார்.
• ஏனெனில் பெறப்பட்ட போக்குவரத்தின் தன்மை (கிட்டத்தட்ட நிகழ்நேரம்) மற்றும் GC இடைநிறுத்தங்கள் நடைமுறையில் ஏற்றுக்கொள்ள முடியாதவை என்பதால், GC உள்ள மொழிகள் நமக்குப் பொருந்தாது,
• ஏனெனில் C உடன் ஒப்பிடக்கூடிய அதிகபட்ச செயல்திறன் உங்களுக்கு தேவை
• ஏனெனில் ரஸ்ட் நமக்கு அச்சமற்ற ஒத்திசைவை வழங்குகிறது, மேலும் அதை C/C++ இல் எழுதத் தொடங்கினால், ப்ரூபெக்கைக் காட்டிலும் இன்னும் அதிகமான பாதிப்புகள், பஃபர் ஓவர்ஃப்ளோக்கள், ரேஸ் நிலைமைகள் மற்றும் பிற பயமுறுத்தும் வார்த்தைகளில் நாம் சிக்கியிருப்போம்.

ரஸ்டுக்கு எதிராக வாதமும் எழுந்தது. ரஸ்டில் திட்டங்களை உருவாக்குவதில் நிறுவனத்திற்கு எந்த அனுபவமும் இல்லை, இப்போது நாங்கள் அதை முக்கிய திட்டத்தில் பயன்படுத்தத் திட்டமிடவில்லை. எனவே, எதுவும் செயல்படாது என்று கடுமையான அச்சங்கள் இருந்தன, ஆனால் நாங்கள் ஒரு வாய்ப்பைப் பெற முடிவு செய்து முயற்சித்தோம்.

நேரம் சென்றது...

இறுதியாக, பல தோல்வியுற்ற முயற்சிகளுக்குப் பிறகு, முதல் வேலை பதிப்பு தயாராக இருந்தது. என்ன நடந்தது? இதுதான் நடந்தது.

ஒவ்வொரு முனையும் அதன் சொந்த அளவீடுகளைப் பெறுகிறது மற்றும் அவற்றைக் குவிக்கிறது, மேலும் இறுதித் திரட்டலுக்கு அவற்றின் முழு தொகுப்பு தேவைப்படும் வகைகளுக்கான அளவீடுகளை ஒருங்கிணைக்காது. ஒருவித விநியோகிக்கப்பட்ட பூட்டு நெறிமுறையால் கணுக்கள் ஒன்றோடொன்று இணைக்கப்பட்டுள்ளன, இது கிரேட் ஒன்னுக்கு அளவீடுகளை அனுப்பத் தகுதியான ஒரே ஒன்றை (இங்கே நாங்கள் அழுதோம்) தேர்ந்தெடுக்க உங்களை அனுமதிக்கிறது. மூலம் இந்த பிரச்சனை தற்போது தீர்க்கப்பட்டு வருகிறது கன்சுல், ஆனால் எதிர்காலத்தில் ஆசிரியரின் லட்சியங்கள் நீட்டிக்கப்படுகின்றன சொந்தம் செயல்படுத்தல் ராஃப்ட், அங்கு மிகவும் தகுதியானவர், நிச்சயமாக, ஒருமித்த தலைவர் முனையாக இருப்பார். ஒருமித்த கருத்துக்கு கூடுதலாக, கணுக்கள் அடிக்கடி (இயல்புநிலையாக வினாடிக்கு ஒரு முறை) அந்த வினாடியில் அவர்கள் சேகரிக்க முடிந்த முன்-தொகுக்கப்பட்ட அளவீடுகளின் பகுதிகளை அண்டை நாடுகளுக்கு அனுப்பும். அளவிடுதல் மற்றும் தவறு சகிப்புத்தன்மை பாதுகாக்கப்பட்டதாக மாறிவிடும் - ஒவ்வொரு முனையிலும் இன்னும் முழு அளவிலான அளவீடுகள் உள்ளன, ஆனால் அளவீடுகள் ஏற்கனவே ஒருங்கிணைக்கப்பட்டு, TCP வழியாக அனுப்பப்பட்டு பைனரி நெறிமுறையில் குறியாக்கம் செய்யப்பட்டுள்ளன, எனவே UDP உடன் ஒப்பிடும்போது நகல் செலவுகள் கணிசமாகக் குறைக்கப்படுகின்றன. அதிக எண்ணிக்கையிலான உள்வரும் அளவீடுகள் இருந்தபோதிலும், திரட்சிக்கு மிகக் குறைந்த நினைவகம் மற்றும் குறைவான CPU தேவைப்படுகிறது. எங்களின் மிகவும் சுருக்கக்கூடிய அளவீடுகளுக்கு, இது சில பத்து மெகாபைட் தரவு மட்டுமே. கூடுதல் போனஸாக, பர்பெக்கைப் போலவே, கிராஃபைட்டில் தேவையற்ற தரவு மீண்டும் எழுதப்படுவதில்லை.

ஒரு எளிய ரவுண்ட் ராபின் மூலம் நெட்வொர்க் உபகரணங்களில் உள்ள முனைகளுக்கு இடையே அளவீடுகளுடன் UDP பாக்கெட்டுகள் சமநிலையற்றவை. நிச்சயமாக, பிணைய வன்பொருள் பாக்கெட்டுகளின் உள்ளடக்கங்களை பாகுபடுத்தாது, எனவே வினாடிக்கு 4M பாக்கெட்டுகளை விட அதிகமாக இழுக்க முடியும், அது பற்றி எதுவும் தெரியாத அளவீடுகளைக் குறிப்பிடவில்லை. ஒவ்வொரு பாக்கெட்டிலும் அளவீடுகள் ஒரு நேரத்தில் வரவில்லை என்பதை நாம் கணக்கில் எடுத்துக் கொண்டால், இந்த இடத்தில் எந்த செயல்திறன் சிக்கல்களையும் நாங்கள் எதிர்பார்க்க மாட்டோம். சேவையகம் செயலிழந்தால், பிணைய சாதனம் விரைவாக (1-2 வினாடிகளுக்குள்) இந்த உண்மையைக் கண்டறிந்து செயலிழந்த சேவையகத்தை சுழற்சியில் இருந்து அகற்றும். இதன் விளைவாக, செயலற்ற (அதாவது, லீடர் அல்லாத) முனைகளை விளக்கப்படங்களில் உள்ள குறைபாடுகளைக் கவனிக்காமல் நடைமுறையில் இயக்கலாம் மற்றும் முடக்கலாம். அதிகபட்சமாக நாம் இழப்பது கடைசி நொடியில் வந்த அளவீடுகளின் ஒரு பகுதியாகும். ஒரு தலைவரின் திடீர் இழப்பு/நிறுத்தம்/மாற்றம் இன்னும் சிறிய ஒழுங்கின்மையை உருவாக்கும் (30 வினாடி இடைவெளி இன்னும் ஒத்திசைவில் இல்லை), ஆனால் முனைகளுக்கு இடையே தொடர்பு இருந்தால், இந்த சிக்கல்களை குறைக்கலாம், எடுத்துக்காட்டாக, ஒத்திசைவு பாக்கெட்டுகளை அனுப்புவதன் மூலம் .

உள் அமைப்பு பற்றி கொஞ்சம். பயன்பாடு, நிச்சயமாக, மல்டித்ரெட் செய்யப்பட்டதாகும், ஆனால் ப்ரூபெக்கில் பயன்படுத்தப்படும் த்ரெடிங் கட்டமைப்பு வேறுபட்டது. ப்ரூபெக்கில் உள்ள நூல்கள் ஒரே மாதிரியானவை - அவை ஒவ்வொன்றும் தகவல் சேகரிப்பு மற்றும் திரட்டுதல் ஆகிய இரண்டிற்கும் பொறுப்பாகும். பயோயினோவில், தொழிலாளர்கள் இரண்டு குழுக்களாகப் பிரிக்கப்பட்டுள்ளனர்: நெட்வொர்க்கிற்கு பொறுப்பானவர்கள் மற்றும் திரட்டலுக்கு பொறுப்பானவர்கள். அளவீடுகளின் வகையைப் பொறுத்து பயன்பாட்டை மிகவும் நெகிழ்வாக நிர்வகிக்க இந்தப் பிரிவு உங்களை அனுமதிக்கிறது: தீவிர ஒருங்கிணைப்பு தேவைப்படும் இடங்களில், நீங்கள் திரட்டிகளைச் சேர்க்கலாம், நெட்வொர்க் ட்ராஃபிக் அதிகமாக இருக்கும் இடத்தில், நெட்வொர்க் ஓட்டங்களின் எண்ணிக்கையைச் சேர்க்கலாம். இந்த நேரத்தில், எங்கள் சேவையகங்களில் நாங்கள் 8 நெட்வொர்க் மற்றும் 4 திரட்டல் ஓட்டங்களில் வேலை செய்கிறோம்.

எண்ணும் (ஒருங்கிணைக்கும் பொறுப்பு) பகுதி மிகவும் சலிப்பை ஏற்படுத்துகிறது. பிணைய ஓட்டங்களால் நிரப்பப்பட்ட இடையகங்கள் எண்ணும் ஓட்டங்களில் விநியோகிக்கப்படுகின்றன, பின்னர் அவை பாகுபடுத்தப்பட்டு ஒருங்கிணைக்கப்படுகின்றன. கோரிக்கையின் பேரில், மற்ற முனைகளுக்கு அனுப்ப அளவீடுகள் வழங்கப்படுகின்றன. முனைகளுக்கு இடையில் தரவை அனுப்புவது மற்றும் தூதரகத்துடன் பணிபுரிவது உட்பட இவை அனைத்தும் ஒத்திசைவின்றி, கட்டமைப்பில் இயங்குகின்றன. டோக்கியோ.

வளர்ச்சியின் போது அதிகமான சிக்கல்கள் அளவீடுகளைப் பெறுவதற்குப் பொறுப்பான பிணையப் பகுதியால் ஏற்பட்டன. நெட்வொர்க் ஓட்டங்களை தனித்தனி நிறுவனங்களாகப் பிரிப்பதன் முக்கிய குறிக்கோள், ஒரு ஓட்டம் செலவழிக்கும் நேரத்தைக் குறைக்க விரும்புவதாகும் இல்லை சாக்கெட்டிலிருந்து தரவைப் படிக்க. ஒத்திசைவற்ற UDP மற்றும் வழக்கமான recvmsg ஐப் பயன்படுத்தும் விருப்பங்கள் விரைவில் மறைந்துவிட்டன: முதலாவது நிகழ்வு செயலாக்கத்திற்கு அதிகமான பயனர்-இட CPU ஐப் பயன்படுத்துகிறது, இரண்டாவது பல சூழல் சுவிட்சுகள் தேவைப்படுகிறது. எனவே இது இப்போது பயன்படுத்தப்படுகிறது recvmmsg பெரிய இடையகங்களுடன் (மற்றும் இடையகங்கள், ஜென்டில்மேன் அதிகாரிகள், உங்களுக்கு ஒன்றுமில்லை!). recvmmsg தேவையில்லாத ஒளி நிகழ்வுகளுக்கு வழக்கமான UDPக்கான ஆதரவு ஒதுக்கப்பட்டுள்ளது. மல்டிமெசேஜ் பயன்முறையில், முக்கிய விஷயத்தை அடைய முடியும்: பெரும்பாலான நேரங்களில், நெட்வொர்க் த்ரெட் OS வரிசையை ரேக் செய்கிறது - சாக்கெட்டிலிருந்து தரவைப் படித்து அதை பயனர்வெளி இடையகத்திற்கு மாற்றுகிறது, எப்போதாவது மட்டுமே நிரப்பப்பட்ட இடையகத்தை வழங்குவதற்கு மாறுகிறது. திரட்டிகள். சாக்கெட்டில் உள்ள வரிசை நடைமுறையில் குவிந்துவிடாது, கைவிடப்பட்ட பாக்கெட்டுகளின் எண்ணிக்கை நடைமுறையில் வளராது.

கருத்து

இயல்புநிலை அமைப்புகளில், இடையக அளவு மிகவும் பெரியதாக அமைக்கப்பட்டுள்ளது. நீங்கள் திடீரென்று சேவையகத்தை முயற்சிக்க முடிவு செய்தால், குறைந்த எண்ணிக்கையிலான அளவீடுகளை அனுப்பிய பிறகு, அவை கிராஃபைட்டில் வராது, நெட்வொர்க் ஸ்ட்ரீம் பஃபரில் இருக்கும். குறைந்த எண்ணிக்கையிலான அளவீடுகளுடன் பணிபுரிய, நீங்கள் bufsize மற்றும் task-queue-size ஆகியவற்றை கட்டமைப்பில் சிறிய மதிப்புகளுக்கு அமைக்க வேண்டும்.

இறுதியாக, சார்ட் பிரியர்களுக்கான சில விளக்கப்படங்கள்.

ஒவ்வொரு சேவையகத்திற்கும் உள்வரும் அளவீடுகளின் எண்ணிக்கை குறித்த புள்ளிவிவரங்கள்: 2 மில்லியனுக்கும் அதிகமான MPS.

முனைகளில் ஒன்றை முடக்குதல் மற்றும் உள்வரும் அளவீடுகளை மறுபகிர்வு செய்தல்.

வெளிச்செல்லும் அளவீடுகளின் புள்ளிவிவரங்கள்: ஒரே ஒரு முனை மட்டுமே எப்போதும் அனுப்புகிறது - ரெய்டு முதலாளி.

ஒவ்வொரு முனையின் செயல்பாட்டின் புள்ளிவிவரங்கள், பல்வேறு கணினி தொகுதிகளில் உள்ள பிழைகளை கணக்கில் எடுத்துக்கொள்கின்றன.

உள்வரும் அளவீடுகளின் விவரம் (மெட்ரிக் பெயர்கள் மறைக்கப்பட்டுள்ளன).

இதையெல்லாம் அடுத்து என்ன செய்ய திட்டமிட்டுள்ளோம்? நிச்சயமாக, குறியீடு எழுது, அடடா...! இந்த திட்டம் முதலில் திறந்த மூலமாக திட்டமிடப்பட்டது மற்றும் அதன் வாழ்நாள் முழுவதும் அப்படியே இருக்கும். எங்களுடைய உடனடித் திட்டங்களில் ராஃப்ட்டின் சொந்தப் பதிப்பிற்கு மாறுவது, பியர் புரோட்டோகாலை மிகவும் சிறியதாக மாற்றுவது, கூடுதல் உள் புள்ளிவிவரங்கள், புதிய வகையான அளவீடுகள், பிழைத் திருத்தங்கள் மற்றும் பிற மேம்பாடுகளை அறிமுகப்படுத்துவது ஆகியவை அடங்கும்.

நிச்சயமாக, திட்டத்தின் வளர்ச்சிக்கு உதவ அனைவரும் வரவேற்கப்படுகிறார்கள்: PR, சிக்கல்களை உருவாக்கவும், முடிந்தால் நாங்கள் பதிலளிப்போம், மேம்படுத்துவோம், முதலியன.

அப்படிச் சொன்னால், அவ்வளவுதான், எங்கள் யானைகளை வாங்குங்கள்!

ஆதாரம்: www.habr.com