பலர் மீள் தேடலுடன் போராடுகிறார்கள். ஆனால் பதிவுகளை "குறிப்பாக பெரிய அளவில்" சேமிக்க நீங்கள் அதைப் பயன்படுத்த விரும்பினால் என்ன நடக்கும்? மேலும் பல தரவு மையங்களில் ஏதேனும் தோல்வியை அனுபவிப்பது வலியற்றதா? எந்த மாதிரியான கட்டிடக்கலையை நீங்கள் செய்ய வேண்டும், நீங்கள் எந்த இடர்பாடுகளில் தடுமாறுவீர்கள்?
Odnoklassniki இல் நாங்கள் பதிவு நிர்வாகத்தின் சிக்கலைத் தீர்க்க மீள் தேடலைப் பயன்படுத்த முடிவு செய்தோம், இப்போது எங்கள் அனுபவத்தை Habr உடன் பகிர்ந்து கொள்கிறோம்: கட்டிடக்கலை மற்றும் ஆபத்துகள் பற்றி.
நான் Pyotr Zaitsev, நான் Odnoklassniki இல் கணினி நிர்வாகியாக பணிபுரிகிறேன். அதற்கு முன், நானும் ஒரு நிர்வாகியாக இருந்தேன், Manticore Search, Sphinx search, Elasticsearch ஆகியவற்றுடன் பணிபுரிந்தேன். ஒருவேளை, வேறொரு ... தேடல் தோன்றினால், நானும் அதனுடன் வேலை செய்வேன். நான் தன்னார்வ அடிப்படையில் பல திறந்த மூல திட்டங்களிலும் பங்கேற்கிறேன்.
நான் ஒட்னோக்ளாஸ்னிகிக்கு வந்தபோது, எலாஸ்டிக் சர்ச்சில் வேலை செய்ய முடியும் என்று நேர்காணலில் பொறுப்பற்ற முறையில் சொன்னேன். நான் அதைக் கண்டுபிடித்து சில எளிய பணிகளை முடித்த பிறகு, அந்த நேரத்தில் இருந்த பதிவு மேலாண்மை அமைப்பைச் சீர்திருத்தும் பெரிய பணி எனக்கு வழங்கப்பட்டது.
தேவைகள்
கணினி தேவைகள் பின்வருமாறு உருவாக்கப்பட்டன:
- கிரேலாக் முன்புறமாக பயன்படுத்தப்பட வேண்டும். நிறுவனத்திற்கு ஏற்கனவே இந்த தயாரிப்பைப் பயன்படுத்திய அனுபவம் இருப்பதால், புரோகிராமர்கள் மற்றும் சோதனையாளர்கள் அதை அறிந்திருந்தனர், அது அவர்களுக்கு நன்கு தெரிந்ததாகவும் வசதியாகவும் இருந்தது.
- தரவு அளவு: வினாடிக்கு சராசரியாக 50-80 ஆயிரம் செய்திகள், ஆனால் ஏதாவது உடைந்தால், போக்குவரத்து எதற்கும் மட்டுப்படுத்தப்படவில்லை, அது வினாடிக்கு 2-3 மில்லியன் வரிகளாக இருக்கலாம்
- தேடல் வினவல்களை செயலாக்குவதற்கான வேகத்திற்கான தேவைகளைப் பற்றி வாடிக்கையாளர்களுடன் கலந்துரையாடிய பின்னர், அத்தகைய அமைப்பைப் பயன்படுத்துவதற்கான பொதுவான முறை இதுதான் என்பதை நாங்கள் உணர்ந்தோம்: மக்கள் கடந்த இரண்டு நாட்களாக தங்கள் விண்ணப்பத்தின் பதிவுகளைத் தேடுகிறார்கள், மேலும் காத்திருக்க விரும்பவில்லை. வடிவமைக்கப்பட்ட வினவலின் முடிவுக்கான இரண்டாவது.
- நிர்வாகிகள், அமைப்பு எவ்வாறு செயல்படுகிறது என்பதை ஆழமாக ஆராயத் தேவையில்லாமல், தேவைப்பட்டால், எளிதாக அளவிடக்கூடியதாக இருக்க வேண்டும் என்று வலியுறுத்தினார்கள்.
- இந்த அமைப்புகளுக்கு அவ்வப்போது தேவைப்படும் ஒரே பராமரிப்பு பணி சில வன்பொருளை மாற்றுவதுதான்.
- கூடுதலாக, Odnoklassniki ஒரு சிறந்த தொழில்நுட்ப பாரம்பரியத்தைக் கொண்டுள்ளது: நாங்கள் தொடங்கும் எந்தவொரு சேவையும் தரவு மைய தோல்வியில் இருந்து தப்பிக்க வேண்டும் (திடீர், திட்டமிடப்படாத மற்றும் முற்றிலும் எந்த நேரத்திலும்).
இந்த திட்டத்தை செயல்படுத்துவதில் கடைசி தேவை எங்களுக்கு மிகவும் செலவாகும், இது பற்றி நான் இன்னும் விரிவாக பேசுவேன்.
சுற்றுச்சூழல்
நாங்கள் நான்கு தரவு மையங்களில் வேலை செய்கிறோம், அதே சமயம் எலாஸ்டிக் தேடல் தரவு முனைகள் மூன்றில் மட்டுமே இருக்க முடியும் (பல தொழில்நுட்பமற்ற காரணங்களுக்காக).
இந்த நான்கு தரவு மையங்களும் தோராயமாக 18 ஆயிரம் வெவ்வேறு பதிவு ஆதாரங்களைக் கொண்டுள்ளன - வன்பொருள், கொள்கலன்கள், மெய்நிகர் இயந்திரங்கள்.
முக்கிய அம்சம்: கொத்து கொள்கலன்களில் தொடங்குகிறது இயற்பியல் இயந்திரங்களில் அல்ல, ஆனால் . கன்டெய்னர்களுக்கு 2Ghz v2.0 போன்ற 4 கோர்கள் உத்தரவாதம் அளிக்கப்படுகிறது, மீதமுள்ள கோர்கள் செயலற்ற நிலையில் இருந்தால் அவற்றை மறுசுழற்சி செய்யும் சாத்தியம் உள்ளது.
வேறு வார்த்தைகளில் கூறுவதானால்:
கட்டமைப்பியல்
நான் முதலில் தீர்வின் பொதுவான வடிவத்தை பின்வருமாறு பார்த்தேன்:
- 3-4 விஐபிகள் கிரேலாக் டொமைனின் A-பதிவுக்குப் பின்னால் உள்ளனர், இது பதிவுகள் அனுப்பப்படும் முகவரியாகும்.
- ஒவ்வொரு விஐபியும் ஒரு எல்விஎஸ் பேலன்சர்.
- அதன் பிறகு, பதிவுகள் கிரேலாக் பேட்டரிக்கு செல்கின்றன, சில தரவு GELF வடிவத்தில் உள்ளது, சில syslog வடிவத்தில் உள்ளன.
- பின்னர் இவை அனைத்தும் எலாஸ்டிக் தேடல் ஒருங்கிணைப்பாளர்களின் பேட்டரிக்கு பெரிய தொகுதிகளாக எழுதப்பட்டுள்ளன.
- மேலும் அவை, தொடர்புடைய தரவு முனைகளுக்கு எழுத மற்றும் படிக்க கோரிக்கைகளை அனுப்புகின்றன.
சொல்லியல்
ஒருவேளை எல்லோரும் சொற்களஞ்சியத்தை விரிவாகப் புரிந்து கொள்ளவில்லை, எனவே நான் அதில் கொஞ்சம் வாழ விரும்புகிறேன்.
மீள் தேடல் பல வகையான முனைகளைக் கொண்டுள்ளது - மாஸ்டர், ஒருங்கிணைப்பாளர், தரவு முனை. வெவ்வேறு பதிவு மாற்றங்கள் மற்றும் வெவ்வேறு கிளஸ்டர்களுக்கிடையேயான தொடர்புக்கு வேறு இரண்டு வகைகள் உள்ளன, ஆனால் பட்டியலிடப்பட்டவற்றை மட்டுமே நாங்கள் பயன்படுத்தினோம்.
மாஸ்டர்
இது கிளஸ்டரில் உள்ள அனைத்து முனைகளையும் பிங் செய்கிறது, புதுப்பித்த கிளஸ்டர் வரைபடத்தை பராமரிக்கிறது மற்றும் அதை முனைகளுக்கு இடையில் விநியோகிக்கிறது, நிகழ்வு தர்க்கத்தை செயலாக்குகிறது மற்றும் பல்வேறு வகையான கிளஸ்டர் வைட் ஹவுஸ்கீப்பிங்கைச் செய்கிறது.
ஒருங்கிணைப்பாளர்
ஒரே ஒரு பணியைச் செய்கிறது: வாடிக்கையாளர்களிடமிருந்து படிக்க அல்லது எழுதும் கோரிக்கைகளை ஏற்றுக்கொள்கிறது மற்றும் இந்த போக்குவரத்தை வழிநடத்துகிறது. எழுதும் கோரிக்கை இருந்தால், பெரும்பாலும், அது தொடர்புடைய குறியீட்டின் எந்தத் துண்டில் வைக்க வேண்டும் என்று மாஸ்டரிடம் கேட்கும், மேலும் கோரிக்கையை மேலும் திருப்பிவிடும்.
தரவு முனை
தரவைச் சேமிக்கிறது, வெளியில் இருந்து வரும் தேடல் வினவல்களைச் செய்கிறது மற்றும் அதில் அமைந்துள்ள துகள்களில் செயல்பாடுகளைச் செய்கிறது.
கிரேலாக்
இது ELK அடுக்கில் உள்ள Logstash உடன் Kibana இணைவது போன்றது. கிரேலாக் ஒரு UI மற்றும் பதிவு செயலாக்க பைப்லைன் இரண்டையும் ஒருங்கிணைக்கிறது. ஹூட்டின் கீழ், கிரேலாக் காஃப்கா மற்றும் ஜூகீப்பரை இயக்குகிறது, இது கிரேலாக்கிற்கு ஒரு கிளஸ்டராக இணைப்பை வழங்குகிறது. எலாஸ்டிக் தேடல் கிடைக்காத பட்சத்தில் கிரேலாக் பதிவுகளை (காஃப்கா) தேக்கக முடியும் மற்றும் தோல்வியுற்ற வாசிப்பு மற்றும் எழுதும் கோரிக்கைகளை மீண்டும் செய்யவும், குறிப்பிட்ட விதிகளின்படி பதிவுகளை குழுவாகவும் குறிக்கவும். லாக்ஸ்டாஷைப் போலவே, கிரேலாக் வரிசைகளை எலாஸ்டிக் தேடலில் எழுதும் முன் மாற்றும் செயல்பாட்டைக் கொண்டுள்ளது.
கூடுதலாக, கிரேலாக் ஒரு உள்ளமைக்கப்பட்ட சேவை கண்டுபிடிப்பைக் கொண்டுள்ளது, இது கிடைக்கக்கூடிய ஒரு எலாஸ்டிக் தேடல் முனையின் அடிப்படையில், முழு க்ளஸ்டர் வரைபடத்தையும் பெறவும், குறிப்பிட்ட குறிச்சொல் மூலம் அதை வடிகட்டவும் அனுமதிக்கிறது, இது குறிப்பிட்ட கொள்கலன்களுக்கு கோரிக்கைகளை அனுப்புவதை சாத்தியமாக்குகிறது.
பார்வைக்கு இது போல் தெரிகிறது:
இது ஒரு குறிப்பிட்ட நிகழ்வின் ஸ்கிரீன் ஷாட். இங்கே நாம் தேடல் வினவலின் அடிப்படையில் ஒரு வரைபடத்தை உருவாக்கி, தொடர்புடைய வரிசைகளைக் காண்பிக்கிறோம்.
குறியீடுகள்
கணினி கட்டமைப்பிற்குத் திரும்புகையில், குறியீட்டு மாதிரியை நாங்கள் எவ்வாறு உருவாக்கினோம் என்பது பற்றி மேலும் விரிவாகப் பேச விரும்புகிறேன், அது அனைத்தும் சரியாக வேலை செய்கிறது.
மேலே உள்ள வரைபடத்தில், இது மிகக் குறைந்த நிலை: மீள் தேடல் தரவு முனைகள்.
இன்டெக்ஸ் என்பது எலாஸ்டிக் சர்ச் ஷார்ட்களால் உருவாக்கப்பட்ட ஒரு பெரிய மெய்நிகர் நிறுவனம். அதில், ஒவ்வொரு துண்டுகளும் லூசீன் குறியீட்டைத் தவிர வேறில்லை. மேலும் ஒவ்வொரு லூசீன் குறியீடும் ஒன்று அல்லது அதற்கு மேற்பட்ட பிரிவுகளைக் கொண்டுள்ளது.
வடிவமைக்கும் போது, அதிக அளவிலான தரவுகளில் வாசிப்பு வேகத்தின் தேவையை பூர்த்தி செய்ய, தரவு முனைகளில் இந்தத் தரவை சமமாக "பரவ" வேண்டும் என்று நாங்கள் கண்டறிந்தோம்.
இதன் விளைவாக, ஒரு குறியீட்டின் துகள்களின் எண்ணிக்கை (பிரதிகளுடன்) தரவு முனைகளின் எண்ணிக்கைக்கு கண்டிப்பாக சமமாக இருக்க வேண்டும். முதலாவதாக, இரண்டிற்கு சமமான பிரதி காரணியை உறுதி செய்வதற்காக (அதாவது, கிளஸ்டரின் பாதியை நாம் இழக்கலாம்). இரண்டாவதாக, குறைந்தபட்சம் பாதி கிளஸ்டரில் கோரிக்கைகளை படிக்கவும் எழுதவும்.
முதலில் சேமிப்பக நேரத்தை 30 நாட்களாக நிர்ணயித்தோம்.
துண்டுகளின் விநியோகத்தை பின்வருமாறு வரைபடமாகக் குறிப்பிடலாம்:
முழு அடர் சாம்பல் செவ்வகமும் ஒரு குறியீடாகும். அதில் இடது சிவப்பு சதுரம் முதன்மைத் துண்டு, குறியீட்டில் முதல். மற்றும் நீல சதுரம் ஒரு பிரதி துண்டு. அவை வெவ்வேறு தரவு மையங்களில் அமைந்துள்ளன.
நாம் மற்றொரு ஷார்ட்டைச் சேர்க்கும்போது, அது மூன்றாவது தரவு மையத்திற்குச் செல்கிறது. மேலும், இறுதியில், இந்த கட்டமைப்பைப் பெறுகிறோம், இது தரவு நிலைத்தன்மையை இழக்காமல் DC ஐ இழக்கச் செய்கிறது:
குறியீடுகளின் சுழற்சி, அதாவது. புதிய குறியீட்டை உருவாக்கி, பழையதை நீக்கி, அதை 48 மணிநேரத்திற்குச் சமமாக மாற்றினோம் (குறியீட்டு பயன்பாட்டின் முறையின்படி: கடைசி 48 மணிநேரம் அடிக்கடி தேடப்படும்).
இந்த குறியீட்டு சுழற்சி இடைவெளி பின்வரும் காரணங்களால் ஏற்படுகிறது:
ஒரு குறிப்பிட்ட தரவு முனையில் ஒரு தேடல் கோரிக்கை வரும்போது, செயல்திறன் பார்வையில், அதன் அளவு கணுவின் இடுப்பின் அளவோடு ஒப்பிடக்கூடியதாக இருந்தால், ஒரு துண்டு வினவப்படும்போது அது அதிக லாபம் தரும். இது குறியீட்டின் "சூடான" பகுதியை குவியலாக வைத்து விரைவாக அணுக அனுமதிக்கிறது. "சூடான பாகங்கள்" நிறைய இருக்கும்போது, குறியீட்டு தேடலின் வேகம் குறைகிறது.
ஒரு முனை ஒரு துண்டில் ஒரு தேடல் வினவலை இயக்கத் தொடங்கும் போது, அது இயற்பியல் இயந்திரத்தின் ஹைப்பர் த்ரெடிங் கோர்களின் எண்ணிக்கைக்கு சமமான பல நூல்களை ஒதுக்குகிறது. ஒரு தேடல் வினவல் அதிக எண்ணிக்கையிலான துண்டுகளை பாதித்தால், நூல்களின் எண்ணிக்கை விகிதாசாரமாக வளரும். இது தேடல் வேகத்தில் எதிர்மறையான தாக்கத்தை ஏற்படுத்துகிறது மற்றும் புதிய தரவின் அட்டவணைப்படுத்தலை எதிர்மறையாக பாதிக்கிறது.
தேவையான தேடல் தாமதத்தை வழங்க, SSD ஐப் பயன்படுத்த முடிவு செய்தோம். கோரிக்கைகளை விரைவாகச் செயல்படுத்த, இந்தக் கொள்கலன்களை ஹோஸ்ட் செய்யும் இயந்திரங்களில் குறைந்தது 56 கோர்கள் இருக்க வேண்டும். 56 இன் எண்ணிக்கை நிபந்தனைக்குட்பட்ட போதுமான மதிப்பாக தேர்ந்தெடுக்கப்பட்டது, இது செயல்பாட்டின் போது மீள் தேடல் உருவாக்கும் நூல்களின் எண்ணிக்கையை தீர்மானிக்கிறது. Elasitcsearch இல், பல த்ரெட் பூல் அளவுருக்கள் நேரடியாக கிடைக்கக்கூடிய கோர்களின் எண்ணிக்கையைப் பொறுத்தது, இது "குறைவான கோர்கள் - அதிக முனைகள்" என்ற கொள்கையின்படி கிளஸ்டரில் தேவையான முனைகளின் எண்ணிக்கையை நேரடியாக பாதிக்கிறது.
இதன் விளைவாக, சராசரியாக ஒரு துண்டின் எடை சுமார் 20 ஜிகாபைட்கள் மற்றும் ஒரு குறியீட்டுக்கு 1 துண்டுகள் இருப்பதைக் கண்டறிந்தோம். அதன்படி, 360 மணி நேரத்திற்கு ஒரு முறை சுழற்றினால், அவற்றில் 48 உள்ளன. ஒவ்வொரு குறியீட்டிலும் 15 நாட்களுக்கு தரவு உள்ளது.
தரவு எழுதுதல் மற்றும் படிக்கும் சுற்றுகள்
இந்த அமைப்பில் தரவு எவ்வாறு பதிவு செய்யப்படுகிறது என்பதைக் கண்டுபிடிப்போம்.
கிரேலாக்கிலிருந்து ஒருங்கிணைப்பாளருக்கு சில கோரிக்கைகள் வந்ததாக வைத்துக்கொள்வோம். எடுத்துக்காட்டாக, 2-3 ஆயிரம் வரிசைகளை அட்டவணைப்படுத்த விரும்புகிறோம்.
ஒருங்கிணைப்பாளர், கிரேலாக்கிடம் இருந்து கோரிக்கையைப் பெற்று, மாஸ்டரிடம் கேள்வி எழுப்புகிறார்: "இண்டெக்ஸ் கோரிக்கையில், நாங்கள் குறிப்பாக ஒரு குறியீட்டைக் குறிப்பிட்டோம், ஆனால் அதை எந்த ஷார்டில் எழுதுவது என்பது குறிப்பிடப்படவில்லை."
மாஸ்டர் பதிலளிக்கிறார்: "இந்த தகவலை ஷார்ட் எண் 71 க்கு எழுதுங்கள்," அதன் பிறகு அது நேரடியாக தொடர்புடைய தரவு முனைக்கு அனுப்பப்படும், அங்கு முதன்மை-துண்டு எண் 71 அமைந்துள்ளது.
அதன் பிறகு பரிவர்த்தனை பதிவு மற்றொரு தரவு மையத்தில் அமைந்துள்ள பிரதி-துண்டுக்கு நகலெடுக்கப்படுகிறது.
கிரேலாக்கிலிருந்து ஒரு தேடல் கோரிக்கை ஒருங்கிணைப்பாளருக்கு வருகிறது. ஒருங்கிணைப்பாளர் அதை குறியீட்டின்படி திருப்பிவிடுகிறார், அதே சமயம் Elasticsearch ஆனது ரவுண்ட்-ராபின் கொள்கையைப் பயன்படுத்தி முதன்மை-துண்டு மற்றும் பிரதி-துண்டு இடையே கோரிக்கைகளை விநியோகிக்கிறது.
180 முனைகள் சமமற்ற முறையில் பதிலளிக்கின்றன, மேலும் அவை பதிலளிக்கும் போது, ஒருங்கிணைப்பாளர் ஏற்கனவே வேகமான தரவு முனைகளால் "துப்பப்பட்ட" தகவலைக் குவித்து வருகிறார். இதற்குப் பிறகு, அனைத்து தகவல்களும் வந்துவிட்டால், அல்லது கோரிக்கை காலக்கெடுவை அடைந்தால், அது நேரடியாக வாடிக்கையாளருக்கு அனைத்தையும் வழங்குகிறது.
இந்த முழு அமைப்பும் சராசரியாக கடந்த 48 மணிநேரத்திற்கான தேடல் வினவல்களை 300-400ms இல் செயலாக்குகிறது, முன்னணி வைல்டு கார்டு கொண்ட வினவல்களைத் தவிர்த்து.
மீள் தேடல் கொண்ட மலர்கள்: ஜாவா அமைப்பு
எல்லாவற்றையும் நாங்கள் முதலில் விரும்பியபடி செயல்பட வைக்க, கிளஸ்டரில் உள்ள பலதரப்பட்ட விஷயங்களை பிழைத்திருத்துவதில் நாங்கள் நீண்ட நேரம் செலவிட்டோம்.
கண்டுபிடிக்கப்பட்ட சிக்கல்களின் முதல் பகுதி, எலாஸ்டிக் தேடலில் ஜாவா முன்னரே கட்டமைக்கப்பட்ட விதத்துடன் தொடர்புடையது.
பிரச்சனை ஒன்று
லூசீன் மட்டத்தில், பின்னணி வேலைகள் இயங்கும் போது, லூசீன் பிரிவு இணைப்புகள் பிழையுடன் தோல்வியடைகின்றன என்ற மிகப் பெரிய எண்ணிக்கையிலான அறிக்கைகளை நாங்கள் பார்த்திருக்கிறோம். அதே நேரத்தில், இது ஒரு OutOfMemoryError பிழை என்பது பதிவுகளில் தெளிவாக இருந்தது. இடுப்பு இலவசம் என்பதை டெலிமெட்ரி மூலம் பார்த்தோம், இந்த அறுவை சிகிச்சை ஏன் தோல்வியடைகிறது என்பது தெளிவாகத் தெரியவில்லை.
லூசீன் குறியீட்டு இணைப்பு இடுப்புக்கு வெளியே நிகழ்கிறது என்று மாறியது. நுகரப்படும் வளங்களின் அடிப்படையில் கொள்கலன்கள் மிகவும் கண்டிப்பாக வரையறுக்கப்பட்டுள்ளன. இந்த ஆதாரங்களில் ஹீப் மட்டுமே பொருந்த முடியும் (heap.size மதிப்பு தோராயமாக RAM க்கு சமமாக இருந்தது), மேலும் சில ஆஃப்-ஹீப் செயல்பாடுகள் சில காரணங்களால் அவை வரம்பிற்கு முன் இருந்த ~500MB க்கு பொருந்தவில்லை என்றால் நினைவக ஒதுக்கீடு பிழையால் செயலிழந்தது.
பிழைத்திருத்தம் மிகவும் அற்பமானது: கொள்கலனுக்கு கிடைக்கும் ரேமின் அளவு அதிகரித்தது, அதன் பிறகு இதுபோன்ற சிக்கல்கள் கூட இருப்பதை மறந்துவிட்டோம்.
பிரச்சனை இரண்டு
கிளஸ்டர் தொடங்கப்பட்ட 4-5 நாட்களுக்குப் பிறகு, தரவு முனைகள் அவ்வப்போது கிளஸ்டரிலிருந்து வெளியேறத் தொடங்கி 10-20 வினாடிகளுக்குப் பிறகு அதை உள்ளிடுவதை நாங்கள் கவனித்தோம்.
நாங்கள் அதைக் கண்டுபிடிக்கத் தொடங்கியபோது, எலாஸ்டிக் தேடலில் உள்ள இந்த ஆஃப்-ஹீப் நினைவகம் எந்த வகையிலும் கட்டுப்படுத்தப்படவில்லை என்று மாறியது. கன்டெய்னருக்கு அதிக நினைவகத்தைக் கொடுத்தபோது, எங்களால் நேரடி இடையகக் குளங்களை பல்வேறு தகவல்களுடன் நிரப்ப முடிந்தது, மேலும் எலாஸ்டிக் தேடலில் இருந்து வெளிப்படையான GC தொடங்கப்பட்ட பின்னரே அது அழிக்கப்பட்டது.
சில சந்தர்ப்பங்களில், இந்த செயல்பாடு நீண்ட நேரம் எடுத்தது, இந்த நேரத்தில் கிளஸ்டர் இந்த முனை ஏற்கனவே வெளியேறியதாகக் குறிக்க முடிந்தது. இந்த பிரச்சனை நன்றாக விவரிக்கப்பட்டுள்ளது .
தீர்வு பின்வருமாறு: இந்த செயல்பாடுகளுக்கு குவியலுக்கு வெளியே நினைவகத்தின் பெரும்பகுதியைப் பயன்படுத்தும் ஜாவாவின் திறனை நாங்கள் மட்டுப்படுத்தினோம். நாங்கள் அதை 16 ஜிகாபைட்டுகளாக (-XX:MaxDirectMemorySize=16g) வரம்பிடுகிறோம், வெளிப்படையான GC அடிக்கடி அழைக்கப்படுவதையும், மிக வேகமாக செயலாக்கப்படுவதையும் உறுதிசெய்து, அதன் மூலம் கிளஸ்டரை சீர்குலைக்காது.
பிரச்சனை மூன்று
"மிகவும் எதிர்பாராத நேரத்தில் கிளஸ்டரை விட்டு வெளியேறும் முனைகளின்" சிக்கல்கள் முடிந்துவிட்டதாக நீங்கள் நினைத்தால், நீங்கள் தவறாக நினைக்கிறீர்கள்.
குறியீட்டுடன் பணியை உள்ளமைக்கும்போது, நாங்கள் mmapfs ஐ தேர்வு செய்தோம் பெரிய பிரிவுகளுடன் புதிய துண்டுகள் மீது. இது மிகவும் தவறு, ஏனெனில் mmapfs ஐப் பயன்படுத்தும் போது கோப்பு ரேமில் மேப் செய்யப்படுகிறது, பின்னர் நாங்கள் மேப் செய்யப்பட்ட கோப்புடன் வேலை செய்கிறோம். இதன் காரணமாக, ஜி.சி பயன்பாட்டில் உள்ள நூல்களை நிறுத்த முயற்சிக்கும்போது, நாம் மிக நீண்ட காலத்திற்கு பாதுகாப்பான இடத்திற்குச் செல்கிறோம், மேலும் அது உயிருடன் இருக்கிறதா என்பது குறித்த மாஸ்டரின் கோரிக்கைகளுக்கு விண்ணப்பம் பதிலளிப்பதை நிறுத்துகிறது. . அதன்படி, மாஸ்டர் கணு இனி கிளஸ்டரில் இல்லை என்று நம்புகிறார். இதற்குப் பிறகு, 5-10 விநாடிகளுக்குப் பிறகு, குப்பை சேகரிப்பான் வேலை செய்கிறது, கணு உயிர்ப்பிக்கிறது, மீண்டும் கிளஸ்டருக்குள் நுழைந்து, துண்டுகளைத் தொடங்கத் தொடங்குகிறது. இது அனைத்தும் "நாம் தகுதியான உற்பத்தி" போல் உணர்ந்தது மற்றும் தீவிரமான எதற்கும் பொருந்தாது.
இந்த நடத்தையிலிருந்து விடுபட, நாங்கள் முதலில் நிலையான நியோஃப்களுக்கு மாறினோம், பின்னர், எலாஸ்டிக் ஐந்தாவது பதிப்பிலிருந்து ஆறாவது இடத்திற்கு மாற்றியபோது, இந்த சிக்கல் மீண்டும் உருவாக்கப்படாத கலப்பினங்களை முயற்சித்தோம். சேமிப்பக வகைகளைப் பற்றி மேலும் படிக்கலாம் .
பிரச்சனை நான்கு
பின்னர் நாங்கள் ஒரு சாதனை நேரத்திற்கு சிகிச்சையளித்த மற்றொரு சுவாரஸ்யமான பிரச்சனை இருந்தது. நாங்கள் 2-3 மாதங்களுக்கு அதைப் பிடித்தோம், ஏனெனில் அதன் முறை முற்றிலும் புரிந்துகொள்ள முடியாதது.
சில சமயங்களில் எங்கள் ஒருங்கிணைப்பாளர்கள் முழு GC க்கு சென்றனர், பொதுவாக மதிய உணவுக்குப் பிறகு, அங்கிருந்து திரும்பவே இல்லை. அதே நேரத்தில், GC தாமதத்தை பதிவு செய்யும் போது, இது போல் தோன்றியது: எல்லாம் நன்றாக இருக்கிறது, நன்றாக இருக்கிறது, நன்றாக இருக்கிறது, பின்னர் திடீரென்று எல்லாம் மிகவும் மோசமாக நடக்கிறது.
முதலில், எங்களிடம் ஒரு தீய பயனர் இருப்பதாக நினைத்தோம், அவர் ஒருவித கோரிக்கையைத் தொடங்குகிறார், அது ஒருங்கிணைப்பாளரை வேலை செய்யும் பயன்முறையில் இருந்து வெளியேற்றியது. நாங்கள் மிக நீண்ட காலமாக கோரிக்கைகளை பதிவு செய்தோம், என்ன நடக்கிறது என்பதைக் கண்டுபிடிக்க முயற்சித்தோம்.
இதன் விளைவாக, ஒரு பயனர் ஒரு பெரிய கோரிக்கையைத் தொடங்கும் தருணத்தில், அது ஒரு குறிப்பிட்ட மீள் தேடல் ஒருங்கிணைப்பாளரைப் பெறுகிறது, சில முனைகள் மற்றவர்களை விட நீண்ட நேரம் பதிலளிக்கின்றன.
ஒருங்கிணைப்பாளர் அனைத்து முனைகளிலிருந்தும் பதிலுக்காகக் காத்திருக்கும்போது, அவர் ஏற்கனவே பதிலளித்த முனைகளிலிருந்து அனுப்பப்பட்ட முடிவுகளைக் குவிப்பார். GC க்கு, நமது குவியல் பயன்பாட்டு முறைகள் மிக விரைவாக மாறுகின்றன. நாங்கள் பயன்படுத்திய GC இந்த பணியை சமாளிக்க முடியவில்லை.
இந்த சூழ்நிலையில் கிளஸ்டரின் நடத்தையை மாற்றுவதற்கு நாங்கள் கண்டறிந்த ஒரே தீர்வு JDK13 க்கு இடம்பெயர்வது மற்றும் Shenandoah குப்பை சேகரிப்பாளரின் பயன்பாடு ஆகும். இது சிக்கலைத் தீர்த்தது, எங்கள் ஒருங்கிணைப்பாளர்கள் வீழ்ச்சியடைவதை நிறுத்தினர்.
இங்குதான் ஜாவாவுடனான பிரச்சனைகள் முடிந்து அலைவரிசை பிரச்சனைகள் தொடங்கின.
மீள் தேடலுடன் "பெர்ரிகள்": செயல்திறன்
செயல்திறனில் உள்ள சிக்கல்கள், எங்கள் கிளஸ்டர் நிலையானதாக வேலை செய்கிறது, ஆனால் குறியீட்டு ஆவணங்களின் எண்ணிக்கையில் உச்சத்தில் மற்றும் சூழ்ச்சிகளின் போது, செயல்திறன் போதுமானதாக இல்லை.
எதிர்கொள்ளும் முதல் அறிகுறி: உற்பத்தியில் சில "வெடிப்புகள்" போது, திடீரென அதிக எண்ணிக்கையிலான பதிவுகள் உருவாக்கப்படும் போது, குறியீட்டு பிழை es_rejected_execution கிரேலாக்கில் அடிக்கடி ஒளிரத் தொடங்குகிறது.
ஒரு தரவு முனையில் thread_pool.write.queue ஆனது, அட்டவணைப்படுத்தல் கோரிக்கையைச் செயலாக்கி, வட்டில் உள்ள ஷார்டில் தகவலைப் பதிவேற்றம் செய்யும் தருணம் வரை Elasticsearch ஆனது, இயல்பாக 200 கோரிக்கைகளை மட்டுமே தேக்கிக்கொள்ள முடியும் என்பதே இதற்குக் காரணம். மற்றும் உள்ளே இந்த அளவுருவைப் பற்றி மிகக் குறைவாகவே கூறப்பட்டுள்ளது. அதிகபட்ச நூல்கள் மற்றும் இயல்புநிலை அளவு மட்டுமே குறிக்கப்படுகிறது.
நிச்சயமாக, நாங்கள் இந்த மதிப்பைத் திருப்பச் சென்று பின்வருவனவற்றைக் கண்டுபிடித்தோம்: குறிப்பாக, எங்கள் அமைப்பில், 300 கோரிக்கைகள் வரை நன்றாக தேக்ககப்படுத்தப்பட்டுள்ளன, மேலும் நாங்கள் மீண்டும் முழு GC க்கு பறக்கிறோம் என்பதில் அதிக மதிப்பு நிறைந்துள்ளது.
கூடுதலாக, இவை ஒரு கோரிக்கைக்குள் வரும் செய்திகளின் தொகுப்பாக இருப்பதால், கிரேலாக்கை மாற்றியமைக்க வேண்டியது அவசியம், இதனால் அது அடிக்கடி மற்றும் சிறிய தொகுதிகளாக அல்ல, ஆனால் பெரிய தொகுதிகளாக அல்லது ஒவ்வொரு 3 வினாடிகளுக்கும் ஒரு முறை தொகுதி இன்னும் முழுமையடையவில்லை என்றால். இந்த விஷயத்தில், எலாஸ்டிக் சர்ச்சில் நாம் எழுதும் தகவல்கள் இரண்டு வினாடிகளில் அல்ல, ஐந்து நிமிடங்களில் (இது எங்களுக்கு மிகவும் பொருத்தமானது) கிடைக்கும், ஆனால் பெரிய அளவில் தள்ளுவதற்கு செய்ய வேண்டிய ரீட்ரேக்களின் எண்ணிக்கை. தகவல்களின் அடுக்கு குறைக்கப்படுகிறது.
எங்காவது ஏதாவது செயலிழந்து, அதைப் பற்றி ஆவேசமாகப் புகாரளிக்கும் தருணங்களில் இது மிகவும் முக்கியமானது, இதனால் முற்றிலும் ஸ்பேம் செய்யப்பட்ட மீள்நிலையைப் பெறக்கூடாது, மேலும் சிறிது நேரம் கழித்து - அடைக்கப்பட்ட பஃபர்களால் செயலற்றதாக இருக்கும் கிரேலாக் முனைகள்.
கூடுதலாக, உற்பத்தியில் இதே வெடிப்புகள் இருந்தபோது, புரோகிராமர்கள் மற்றும் சோதனையாளர்களிடமிருந்து புகார்களைப் பெற்றோம்: அவர்களுக்கு உண்மையில் இந்த பதிவுகள் தேவைப்படும் தருணத்தில், அவை மிக மெதுவாக வழங்கப்பட்டன.
அவர்கள் அதை கண்டுபிடிக்க ஆரம்பித்தார்கள். ஒருபுறம், தேடல் வினவல்கள் மற்றும் அட்டவணைப்படுத்தல் வினவல்கள் இரண்டும் ஒரே இயற்பியல் இயந்திரங்களில் செயலாக்கப்பட்டன என்பது தெளிவாகத் தெரிந்தது, மேலும் ஒரு வழி அல்லது வேறு சில குறைபாடுகள் இருக்கும்.
ஆனால் மீள் தேடலின் ஆறாவது பதிப்புகளில், சீரற்ற ரவுண்ட்-ராபின் கொள்கையின்படி அல்லாமல் தொடர்புடைய தரவு முனைகளுக்கு இடையில் வினவல்களை விநியோகிக்க உங்களை அனுமதிக்கும் ஒரு அல்காரிதம் தோன்றியதன் காரணமாக இது ஓரளவு தவிர்க்கப்படலாம். ஷார்ட் மிகவும் பிஸியாக இருக்கலாம், விரைவாக பதிலளிக்க எந்த வழியும் இருக்காது), ஆனால் இந்த கோரிக்கையை குறைந்த ஏற்றப்பட்ட கொள்கலனுக்கு பிரதி-துண்டுடன் அனுப்பவும், இது மிக வேகமாக பதிலளிக்கும். வேறு வார்த்தைகளில் கூறுவதானால், நாங்கள் use_adaptive_replica_selection என்ற இடத்திற்கு வந்துள்ளோம்: true.
படிக்கும் படம் இப்படியாகத் தொடங்குகிறது:
இந்த அல்காரிதத்திற்கு மாறுவது, எங்களிடம் எழுதுவதற்கு அதிக பதிவுகள் இருந்த தருணங்களில் வினவல் நேரத்தை கணிசமாக மேம்படுத்த முடிந்தது.
இறுதியாக, முக்கிய பிரச்சனை தரவு மையத்தின் வலியற்ற நீக்கம் ஆகும்.
ஒரு DC உடனான தொடர்பை இழந்த உடனேயே கிளஸ்டரிலிருந்து நாம் விரும்புவது:
- தோல்வியுற்ற தரவு மையத்தில் தற்போதைய மாஸ்டர் இருந்தால், அது மீண்டும் தேர்ந்தெடுக்கப்பட்டு மற்றொரு DC இல் உள்ள மற்றொரு முனைக்கு ஒரு பாத்திரமாக மாற்றப்படும்.
- கிளஸ்டரிலிருந்து அணுக முடியாத அனைத்து முனைகளையும் மாஸ்டர் விரைவாக அகற்றுவார்.
- மீதமுள்ளவற்றின் அடிப்படையில், அவர் புரிந்துகொள்வார்: தொலைந்து போன தரவு மையத்தில் எங்களிடம் இது போன்ற முதன்மைத் துண்டுகள் இருந்தன, மீதமுள்ள தரவு மையங்களில் நிரப்பு பிரதி துண்டுகளை விரைவாக விளம்பரப்படுத்துவார், மேலும் நாங்கள் தரவை அட்டவணைப்படுத்துவதைத் தொடர்வோம்.
- இதன் விளைவாக, கிளஸ்டரின் எழுதுதல் மற்றும் வாசிப்பு செயல்திறன் படிப்படியாக குறையும், ஆனால் பொதுவாக எல்லாம் மெதுவாக இருந்தாலும், நிலையானதாக இருக்கும்.
அது முடிந்தவுடன், இதுபோன்ற ஒன்றை நாங்கள் விரும்புகிறோம்:
மேலும் நாங்கள் பின்வருவனவற்றைப் பெற்றோம்:
அது நடந்தது எப்படி?
தரவு மையம் விழுந்தவுடன், எங்கள் மாஸ்டர் தடையாக மாறினார்.
Почему?
உண்மை என்னவென்றால், மாஸ்டருக்கு ஒரு டாஸ்க்பேட்சர் உள்ளது, இது கிளஸ்டரில் சில பணிகள் மற்றும் நிகழ்வுகளை விநியோகிக்க பொறுப்பாகும். எந்த முனை வெளியேறுதல், பிரதியிலிருந்து முதன்மைக்கு ஒரு துண்டின் எந்தவொரு விளம்பரமும், எங்காவது ஒரு ஷார்ட்டை உருவாக்குவதற்கான எந்தவொரு பணியும் - இவை அனைத்தும் முதலில் TaskBatcher க்கு செல்கிறது, அங்கு அது தொடர்ச்சியாகவும் ஒரு தொடரிலும் செயலாக்கப்படுகிறது.
ஒரு தரவு மையத்தை திரும்பப் பெறும் நேரத்தில், எஞ்சியிருக்கும் தரவு மையங்களில் உள்ள அனைத்து தரவு முனைகளும், "நாங்கள் அத்தகைய துண்டுகளை இழந்துவிட்டோம்" என்று மாஸ்டருக்குத் தெரிவிப்பது அவர்களின் கடமையாகக் கருதப்பட்டது.
அதே நேரத்தில், எஞ்சியிருக்கும் தரவு முனைகள் இந்த தகவலை தற்போதைய மாஸ்டருக்கு அனுப்பி, அவர் அதை ஏற்றுக்கொண்டார் என்பதை உறுதிப்படுத்த காத்திருக்க முயன்றனர். மாஸ்டர் அவர் பதிலளிக்கக்கூடியதை விட வேகமாக பணிகளைப் பெற்றதால், அவர்கள் இதற்காக காத்திருக்கவில்லை. கணுக்கள் மீண்டும் மீண்டும் கோரிக்கைகளை முடிக்கின்றன, மேலும் இந்த நேரத்தில் மாஸ்டர் அவர்களுக்கு பதிலளிக்க கூட முயற்சிக்கவில்லை, ஆனால் முன்னுரிமையின்படி கோரிக்கைகளை வரிசைப்படுத்தும் பணியில் முழுமையாக உள்வாங்கப்பட்டார்.
டெர்மினல் வடிவத்தில், தரவு முனைகள் மாஸ்டரை ஸ்பேம் செய்து முழு GC க்கு சென்றது. அதன்பிறகு, எங்கள் முதன்மைப் பாத்திரம் சில அடுத்த முனைக்கு நகர்ந்தது, அதற்கும் அதே விஷயம் நடந்தது, இதன் விளைவாக கிளஸ்டர் முற்றிலும் சரிந்தது.
நாங்கள் அளவீடுகளை எடுத்தோம், இது சரி செய்யப்பட்ட பதிப்பு 6.4.0 க்கு முன், கிளஸ்டரை முழுவதுமாக மூடுவதற்கு 10 இல் 360 தரவு முனைகளை ஒரே நேரத்தில் வெளியிடுவது எங்களுக்கு போதுமானதாக இருந்தது.
இது இப்படி இருந்தது:
பதிப்பு 6.4.0 க்குப் பிறகு, இந்த பயங்கரமான பிழை சரி செய்யப்பட்டது, தரவு முனைகள் மாஸ்டரைக் கொல்வதை நிறுத்தியது. ஆனால் அது அவரை "புத்திசாலி" ஆக்கவில்லை. அதாவது: நாம் 2, 3 அல்லது 10 (ஒன்றைத் தவிர வேறு எந்த எண்) தரவு முனைகளை வெளியிடும் போது, முனை A விட்டுவிட்டதாகக் கூறும் சில முதல் செய்தியை மாஸ்டர் பெறுகிறார், மேலும் இதைப் பற்றி முனை B, முனை C, முனை D என்று சொல்ல முயற்சிக்கிறார்.
தற்சமயம், 20-30 வினாடிகளுக்குச் சமமாக யாரிடமாவது ஏதாவது ஒன்றைச் சொல்லும் முயற்சிகளுக்கான காலக்கெடுவை அமைப்பதன் மூலம் மட்டுமே இதைச் சமாளிக்க முடியும், இதனால் கிளஸ்டருக்கு வெளியே நகரும் தரவு மையத்தின் வேகத்தைக் கட்டுப்படுத்தலாம்.
கொள்கையளவில், திட்டத்தின் ஒரு பகுதியாக இறுதி தயாரிப்புக்கு ஆரம்பத்தில் வழங்கப்பட்ட தேவைகளுக்கு இது பொருந்துகிறது, ஆனால் "தூய அறிவியலின்" பார்வையில் இது ஒரு பிழை. இது, பதிப்பு 7.2 இல் டெவலப்பர்களால் வெற்றிகரமாக சரி செய்யப்பட்டது.
மேலும், ஒரு குறிப்பிட்ட தரவு முனை வெளியேறியபோது, அதன் வெளியேறுதல் பற்றிய தகவல்களைப் பரப்புவது, முழுக் கிளஸ்டருக்கும் அதில் இதுபோன்ற முதன்மைத் துண்டுகள் இருப்பதாகச் சொல்வதை விட முக்கியமானது (மற்றொரு தரவில் பிரதி-துண்டுகளை மேம்படுத்துவதற்காக). முதன்மை மையத்தில், மற்றும் தகவல்களில் அவற்றை எழுதலாம்).
எனவே, அனைத்தும் ஏற்கனவே இறந்துவிட்டால், வெளியிடப்பட்ட தரவு முனைகள் உடனடியாக பழையதாகக் குறிக்கப்படவில்லை. அதன்படி, அனைத்து பிங்களும் வெளியிடப்பட்ட தரவு முனைகளுக்கு நேரம் முடிவடையும் வரை காத்திருக்க வேண்டிய கட்டாயத்தில் இருக்கிறோம், அதன்பிறகுதான் எங்கள் கிளஸ்டர் அங்கேயும், அங்கேயும், அங்கேயும் தொடர்ந்து தகவல்களைப் பதிவு செய்ய வேண்டும் என்று சொல்லத் தொடங்குகிறது. இதைப் பற்றி மேலும் படிக்கலாம் .
இதன் விளைவாக, இன்று ஒரு தரவு மையத்தைத் திரும்பப் பெறுவதற்கான செயல்பாடு, அவசர நேரத்தில் 5 நிமிடங்கள் ஆகும். இவ்வளவு பெரிய மற்றும் விகாரமான கோலோசஸுக்கு, இது ஒரு நல்ல முடிவு.
இதன் விளைவாக, நாங்கள் பின்வரும் முடிவை எடுத்தோம்:
- எங்களிடம் 360 ஜிகாபைட் வட்டுகளுடன் 700 தரவு முனைகள் உள்ளன.
- இதே தரவு முனைகள் மூலம் போக்குவரத்தை வழிநடத்த 60 ஒருங்கிணைப்பாளர்கள்.
- 40 க்கு முந்தைய பதிப்புகளில் இருந்து 6.4.0 முதுநிலைகளை நாங்கள் விட்டுச் சென்றுள்ளோம் - தரவு மையத்தை திரும்பப் பெறுவதில் இருந்து தப்பிப்பதற்காக, முதுநிலைக் குழுவைக் கொண்டிருப்பதற்கு உத்தரவாதம் அளிக்கும் பொருட்டு பல இயந்திரங்களை இழக்க மனதளவில் தயாராக இருந்தோம். மிக மோசமான சூழ்நிலை
- ஒரு கொள்கலனில் பாத்திரங்களை இணைப்பதற்கான எந்தவொரு முயற்சியும் விரைவில் அல்லது பின்னர் சுமையின் கீழ் முனை உடைந்து விடும் என்ற உண்மையை சந்தித்தது.
- முழு க்ளஸ்டரும் 31 ஜிகாபைட்களின் குவியலைப் பயன்படுத்துகிறது: அளவைக் குறைப்பதற்கான அனைத்து முயற்சிகளும் முன்னணி வைல்டு கார்டுடன் கூடிய கனமான தேடல் வினவல்களில் சில முனைகளைக் கொல்லும் அல்லது எலாஸ்டிக் சர்ச்சில் சர்க்யூட் பிரேக்கரைப் பெறுவதற்கு வழிவகுத்தன.
- கூடுதலாக, தேடல் செயல்திறனை உறுதிப்படுத்த, மாஸ்டரில் எங்களுக்கு கிடைத்த இடையூறில் முடிந்தவரை சில நிகழ்வுகளைச் செயல்படுத்த, கிளஸ்டரில் உள்ள பொருட்களின் எண்ணிக்கையை முடிந்தவரை சிறியதாக வைத்திருக்க முயற்சித்தோம்.
இறுதியாக கண்காணிப்பு பற்றி
இவை அனைத்தும் திட்டமிட்டபடி செயல்படுவதை உறுதிசெய்ய, பின்வருவனவற்றை நாங்கள் கண்காணிக்கிறோம்:
- ஒவ்வொரு தரவு முனையும் அது இருப்பதை எங்கள் மேகக்கணிக்கு தெரிவிக்கிறது, மேலும் அதில் இதுபோன்ற மற்றும் அத்தகைய துண்டுகள் உள்ளன. எங்காவது எதையாவது அணைக்கும்போது, 2-3 வினாடிகளுக்குப் பிறகு, A மையத்தில் நாம் 2, 3 மற்றும் 4 முனைகளை அணைத்தோம் என்று கிளஸ்டர் தெரிவிக்கிறது - இதன் பொருள் மற்ற தரவு மையங்களில் ஒரே ஒரு துண்டு மட்டுமே இருக்கும் அந்த முனைகளை நாம் எந்த சூழ்நிலையிலும் அணைக்க முடியாது. விட்டு.
- எஜமானரின் நடத்தையின் தன்மையை அறிந்து, நிலுவையில் உள்ள பணிகளின் எண்ணிக்கையை மிகவும் கவனமாகப் பார்க்கிறோம். ஒரு தடைபட்ட பணி கூட, அது சரியான நேரத்தில் முடிவடையவில்லை என்றால், கோட்பாட்டளவில் சில அவசரகால சூழ்நிலைகளில், எடுத்துக்காட்டாக, முதன்மையில் ஒரு பிரதி துண்டின் விளம்பரம் வேலை செய்யாது, அதனால்தான் அட்டவணைப்படுத்தல் வேலை செய்வதை நிறுத்தும்.
- குப்பை சேகரிப்புத் தாமதங்களை நாங்கள் மிகவும் உன்னிப்பாகப் பார்க்கிறோம், ஏனெனில் தேர்வுமுறையின் போது ஏற்கனவே இதில் பெரும் சிரமங்களைச் சந்தித்துள்ளோம்.
- தடை எங்கே என்பதை முன்கூட்டியே புரிந்து கொள்ள நூல் மூலம் நிராகரிக்கிறது.
- சரி, ஹீப், ரேம் மற்றும் I/O போன்ற நிலையான அளவீடுகள்.
கண்காணிப்பைக் கட்டமைக்கும்போது, எலாஸ்டிக் தேடலில் த்ரெட் பூலின் அம்சங்களை நீங்கள் கணக்கில் எடுத்துக்கொள்ள வேண்டும். உள்ளமைவு விருப்பங்கள் மற்றும் தேடல் மற்றும் அட்டவணைப்படுத்தலுக்கான இயல்புநிலை மதிப்புகளை விவரிக்கிறது, ஆனால் thread_pool.management பற்றி முற்றிலும் அமைதியாக உள்ளது.இந்த நூல்கள் செயலாக்கம், குறிப்பாக, _cat/shards போன்ற வினவல்கள் மற்றும் பிற ஒத்தவை, இவை கண்காணிப்பை எழுதும் போது பயன்படுத்த வசதியாக இருக்கும். பெரிய கிளஸ்டர், ஒரு யூனிட் நேரத்திற்கு இதுபோன்ற கோரிக்கைகள் செயல்படுத்தப்படும், மேலும் மேற்கூறிய thread_pool.management அதிகாரப்பூர்வ ஆவணத்தில் வழங்கப்படாமல், இயல்புநிலையாக 5 நூல்களுக்கு வரம்பிடப்படுகிறது, இது மிக விரைவாக அகற்றப்படும். எந்த கண்காணிப்பு சரியாக வேலை செய்வதை நிறுத்துகிறது.
முடிவில் நான் என்ன சொல்ல விரும்புகிறேன்: நாங்கள் அதை செய்தோம்! எங்களுடைய புரோகிராமர்கள் மற்றும் டெவலப்பர்களுக்கு எந்தவொரு சூழ்நிலையிலும், உற்பத்தியில் என்ன நடக்கிறது என்பது பற்றிய தகவல்களை விரைவாகவும் நம்பகத்தன்மையுடனும் வழங்கக்கூடிய ஒரு கருவியை எங்களால் வழங்க முடிந்தது.
ஆம், இது மிகவும் சிக்கலானதாக மாறியது, ஆயினும்கூட, நாங்கள் ஏற்கனவே உள்ள தயாரிப்புகளில் எங்கள் விருப்பங்களை பொருத்த முடிந்தது, அதை நாங்கள் சரிசெய்து மீண்டும் எழுத வேண்டியதில்லை.
ஆதாரம்: www.habr.com