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

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

நான் ஆல்வினை சோதனைக்கு உட்படுத்தும் முன், வினாடிக்கு 40k வினவல்கள் (QPS) மூலம் நிறைய சோதனைகளை நடத்தினேன், இவை அனைத்தும் 10msக்கும் குறைவான தாமதத்தைக் காட்டுகின்றன. அவர்களின் முடிவுகளுடன் நான் உடன்படவில்லை என்று அறிவிக்க நான் தயாராக இருந்தேன். ஆனால் கடிதத்தை இன்னொரு முறை பார்த்தேன், நான் புதிதாக ஒன்றைக் கவனித்தேன்: அவர்கள் குறிப்பிட்டுள்ள நிபந்தனைகளை நான் சரியாகச் சோதிக்கவில்லை, அவர்களின் QPS என்னுடையதை விட மிகவும் குறைவாக இருந்தது. நான் 40k QPS இல் சோதனை செய்தேன், ஆனால் அவை 1k இல் மட்டுமே. நான் மற்றொரு பரிசோதனையை நடத்தினேன், இந்த முறை குறைந்த QPS உடன், அவர்களை சமாதானப்படுத்துவதற்காக.

நான் இதைப் பற்றி வலைப்பதிவு செய்வதால், அவர்களின் எண்கள் சரியானவை என்பதை நீங்கள் ஏற்கனவே கண்டுபிடித்திருக்கலாம். எனது மெய்நிகர் கிளையண்டை மீண்டும் மீண்டும் சோதித்தேன், அதே முடிவுடன்: குறைந்த எண்ணிக்கையிலான கோரிக்கைகள் தாமதத்தை அதிகரிப்பது மட்டுமல்லாமல், 10 msக்கும் அதிகமான தாமதத்துடன் கோரிக்கைகளின் எண்ணிக்கையையும் அதிகரிக்கிறது. வேறு வார்த்தைகளில் கூறுவதானால், 40k QPS இல் வினாடிக்கு 50 கோரிக்கைகள் 50 ms ஐத் தாண்டினால், 1k QPS இல் ஒவ்வொரு வினாடிக்கும் 100 ms க்கு மேல் 50 கோரிக்கைகள் இருந்தன. முரண்!

தேடலைக் குறைக்கிறது

பல கூறுகளைக் கொண்ட விநியோகிக்கப்பட்ட அமைப்பில் தாமதப் பிரச்சனையை எதிர்கொள்ளும் போது, ​​சந்தேக நபர்களின் குறுகிய பட்டியலை உருவாக்குவது முதல் படியாகும். ஆல்வினின் கட்டிடக்கலையை இன்னும் கொஞ்சம் ஆழமாகப் பார்ப்போம்:

ஒரு நல்ல தொடக்க புள்ளியானது நிறைவு செய்யப்பட்ட I/O மாற்றங்களின் பட்டியல் (நெட்வொர்க் அழைப்புகள்/வட்டு தேடல்கள் போன்றவை). தாமதம் எங்கே என்று கண்டுபிடிக்க முயற்சிப்போம். கிளையண்டுடன் வெளிப்படையான I/O தவிர, ஆல்வின் ஒரு கூடுதல் படி எடுக்கிறார்: அவர் டேட்டா ஸ்டோரை அணுகுகிறார். இருப்பினும், இந்த சேமிப்பகம் ஆல்வின் அதே கிளஸ்டரில் செயல்படுகிறது, எனவே அங்குள்ள தாமதமானது கிளையண்டை விட குறைவாக இருக்க வேண்டும். எனவே, சந்தேக நபர்களின் பட்டியல்:

1. கிளையண்டிலிருந்து ஆல்வினுக்கு நெட்வொர்க் அழைப்பு.
2. ஆல்வினிடமிருந்து டேட்டா ஸ்டோருக்கு நெட்வொர்க் அழைப்பு.
3. தரவு சேமிப்பகத்தில் வட்டில் தேடவும்.
4. தரவுக் கிடங்கில் இருந்து ஆல்வினுக்கு நெட்வொர்க் அழைப்பு.
5. ஆல்வினிடமிருந்து கிளையண்டிற்கு நெட்வொர்க் அழைப்பு.

சில புள்ளிகளைக் கடக்க முயற்சிப்போம்.

தரவு சேமிப்பிற்கும் இதற்கும் எந்த சம்பந்தமும் இல்லை

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

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

1. கிளையண்டிலிருந்து ஆல்வினுக்கு நெட்வொர்க் அழைப்பு.
2. ஆல்வினிடமிருந்து கிளையண்டிற்கு நெட்வொர்க் அழைப்பு.

நன்று! பட்டியல் விரைவாக சுருங்கி வருகிறது. கிட்டத்தட்ட காரணத்தை கண்டுபிடித்துவிட்டதாக நினைத்தேன்.

gRPC

புதிய பிளேயரை உங்களுக்கு அறிமுகப்படுத்துவதற்கான நேரம் இது: gRPC. இது செயல்பாட்டில் உள்ள தகவல்தொடர்புக்கான Google வழங்கும் திறந்த மூல நூலகமாகும் RPC ஐ... இருந்தாலும் gRPC நன்கு உகந்ததாக மற்றும் பரவலாகப் பயன்படுத்தப்படுகிறது, இந்த அளவுள்ள கணினியில் இதைப் பயன்படுத்துவது இதுவே எனது முதல் முறையாகும், மேலும் எனது செயலாக்கம் மிகச்சிறப்பானதாக இருக்கும் என்று நான் எதிர்பார்த்தேன்.

கிடைக்கும் gRPC அடுக்கில் ஒரு புதிய கேள்வி எழுந்தது: ஒருவேளை அது எனது செயலாக்கமாக இருக்கலாம் அல்லது நானாக இருக்கலாம் gRPC தாமத பிரச்சனையை ஏற்படுத்துமா? புதிய சந்தேக நபரை பட்டியலில் சேர்த்தல்:

1. வாடிக்கையாளர் நூலகத்தை அழைக்கிறார் gRPC
2. நூலகம் gRPC கிளையண்டில் உள்ள நூலகத்திற்கு பிணைய அழைப்பை ஏற்படுத்துகிறது gRPC சேவையகத்தில்
3. நூலகம் gRPC ஆல்வின் தொடர்புகள் (பிங்-பாங் சர்வரில் செயல்பாடு இல்லை)

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

குறிப்பு: மேலே உள்ள பட்டியல் சற்று எளிமைப்படுத்தப்பட்டுள்ளது, ஏனெனில் gRPC உங்கள் சொந்த (டெம்ப்ளேட்?) த்ரெடிங் மாதிரியைப் பயன்படுத்துவதை சாத்தியமாக்குகிறது, இதில் செயல்படுத்தல் அடுக்கு பின்னிப்பிணைந்துள்ளது gRPC மற்றும் பயனர் செயல்படுத்தல். எளிமைக்காக, இந்த மாதிரியை நாங்கள் கடைப்பிடிப்போம்.

விவரக்குறிப்பு எல்லாவற்றையும் சரிசெய்யும்

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

நான் நான்கு சுயவிவரங்களை எடுத்தேன்: அதிக QPS (குறைந்த தாமதம்) மற்றும் குறைந்த QPS (அதிக தாமதம்) கொண்ட பிங்-பாங் சேவையகத்துடன், கிளையன்ட் பக்கத்திலும் சர்வர் பக்கத்திலும். மற்றும் வழக்கில், நான் ஒரு மாதிரி செயலி சுயவிவரத்தை எடுத்து. சுயவிவரங்களை ஒப்பிடும்போது, ​​நான் வழக்கமாக ஒரு ஒழுங்கற்ற அழைப்பு அடுக்கைத் தேடுவேன். எடுத்துக்காட்டாக, அதிக தாமதத்துடன் மோசமான பக்கத்தில் இன்னும் பல சூழல் சுவிட்சுகள் உள்ளன (10 மடங்கு அல்லது அதற்கு மேற்பட்டவை). ஆனால் என் விஷயத்தில், சூழல் சுவிட்சுகளின் எண்ணிக்கை கிட்டத்தட்ட ஒரே மாதிரியாக இருந்தது. என் திகில், அங்கு குறிப்பிடத்தக்க எதுவும் இல்லை.

கூடுதல் பிழைத்திருத்தம்

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

என்ன என்றால்

ஆரம்பத்திலிருந்தே, குறிப்பிட்ட 50ms தாமதம் குறித்து நான் கவலைப்பட்டேன். இது மிகவும் பெரிய நேரம். எந்தப் பகுதி இந்தப் பிழையை ஏற்படுத்துகிறது என்பதைச் சரியாகக் கண்டுபிடிக்கும் வரை குறியீட்டிலிருந்து துண்டுகளை வெட்டிவிடுவேன் என்று முடிவு செய்தேன். பின்னர் ஒரு சோதனை வந்தது.

வழக்கம் போல், பின்னோக்கிப் பார்த்தால் எல்லாம் தெளிவாகத் தெரிந்தது. நான் ஆல்வின் இருந்த அதே கணினியில் கிளையண்டை வைத்தேன் - மேலும் ஒரு கோரிக்கையை அனுப்பினேன் localhost. மற்றும் தாமதத்தின் அதிகரிப்பு போய்விட்டது!

நெட்வொர்க்கில் ஏதோ தவறு உள்ளது.

நெட்வொர்க் பொறியாளர் திறன்களைக் கற்றல்

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

அதிர்ஷ்டவசமாக, இணையம் கற்றுக்கொள்ள விரும்புபவர்களை விரும்புகிறது. பிங் மற்றும் ட்ரேசர்ட்டின் கலவையானது நெட்வொர்க் போக்குவரத்து சிக்கல்களை பிழைத்திருத்துவதற்கு போதுமான தொடக்கமாகத் தோன்றியது.

முதலில், நான் தொடங்கினேன் PsPing ஆல்வின் TCP போர்ட்டிற்கு. நான் இயல்புநிலை அமைப்புகளைப் பயன்படுத்தினேன் - சிறப்பு எதுவும் இல்லை. ஆயிரத்திற்கும் மேற்பட்ட பிங்களில், வெப்பமயமாதலுக்கான முதல் பிங்ஸைத் தவிர, எதுவும் 10 எம்எஸ்க்கு மேல் இல்லை. இது 50வது சதவிகிதத்தில் 99 எம்எஸ் தாமதம் அதிகரிப்பதற்கு முரணானது: அங்கு, ஒவ்வொரு 100 கோரிக்கைகளுக்கும், 50 எம்எஸ் தாமதத்துடன் ஒரு கோரிக்கையைப் பார்த்திருக்க வேண்டும்.

பிறகு முயற்சித்தேன் சுவடு: ஆல்வினுக்கும் வாடிக்கையாளருக்கும் இடையே உள்ள பாதையில் ஒரு முனையில் சிக்கல் இருக்கலாம். ஆனால் ட்ரேசரும் வெறுங்கையுடன் திரும்பினார்.

அதனால் தாமதத்தை ஏற்படுத்தியது எனது குறியீடு, gRPC செயல்படுத்தல் அல்லது நெட்வொர்க் அல்ல. இதை நான் புரிந்து கொள்ளவே மாட்டேன் என்று நான் கவலைப்பட ஆரம்பித்தேன்.

இப்போது நாம் எந்த OS இல் இருக்கிறோம்

gRPC லினக்ஸில் பரவலாகப் பயன்படுத்தப்படுகிறது, ஆனால் விண்டோஸில் கவர்ச்சியானது. நான் ஒரு பரிசோதனையை முயற்சிக்க முடிவு செய்தேன், அது வேலை செய்தது: நான் ஒரு லினக்ஸ் மெய்நிகர் இயந்திரத்தை உருவாக்கி, லினக்ஸுக்கு ஆல்வினை தொகுத்து, அதை பயன்படுத்தினேன்.

என்ன நடந்தது என்பது இங்கே: லினக்ஸ் பிங்-பாங் சேவையகம் இதேபோன்ற விண்டோஸ் ஹோஸ்டைப் போன்ற தாமதங்களைக் கொண்டிருக்கவில்லை, இருப்பினும் தரவு மூலமானது வேறுபட்டதாக இல்லை. விண்டோஸிற்கான ஜிஆர்பிசி செயல்படுத்தலில் சிக்கல் உள்ளது என்று மாறிவிடும்.

நாகலின் வழிமுறை

இந்த நேரமெல்லாம் நான் ஒரு கொடியைக் காணவில்லை என்று நினைத்தேன் gRPC. அது உண்மையில் என்னவென்று இப்போது எனக்குப் புரிகிறது gRPC விண்டோஸ் கொடி காணவில்லை. உள்ளக RPC லைப்ரரியைக் கண்டேன், அது எல்லா கொடிகளுக்கும் நன்றாக வேலை செய்யும் என்று நான் நம்புகிறேன் Winsock. நான் இந்த கொடிகள் அனைத்தையும் gRPC இல் சேர்த்தேன் மற்றும் Windows இல் ஆல்வினை, இணைக்கப்பட்ட Windows ping-pong சர்வரில் பயன்படுத்தினேன்!

கிட்டத்தட்ட முடிந்தது: பின்னடைவு திரும்பும் வரை, சேர்க்கப்பட்ட கொடிகளை ஒவ்வொன்றாக அகற்றத் தொடங்கினேன், அதனால் என்னால் காரணத்தைக் குறிப்பிட முடியும். அது இழிவானது TCP_NODELAY, நாக்லின் அல்காரிதம் சுவிட்ச்.

நாகலின் வழிமுறை பாக்கெட் அளவு குறிப்பிட்ட எண்ணிக்கையிலான பைட்டுகளை மீறும் வரை செய்திகளை அனுப்புவதை தாமதப்படுத்துவதன் மூலம் நெட்வொர்க்கில் அனுப்பப்படும் பாக்கெட்டுகளின் எண்ணிக்கையை குறைக்க முயற்சிக்கிறது. சராசரி பயனருக்கு இது நன்றாக இருந்தாலும், நிகழ்நேர சேவையகங்களுக்கு இது அழிவுகரமானது, ஏனெனில் OS சில செய்திகளை தாமதப்படுத்தும், இது குறைந்த QPS இல் பின்னடைவை ஏற்படுத்தும். யு gRPC இந்தக் கொடியானது TCP சாக்கெட்டுகளுக்கான Linux செயலாக்கத்தில் அமைக்கப்பட்டது, ஆனால் Windows இல் இல்லை. நான் இது சரி செய்யப்பட்டது.

முடிவுக்கு

குறைந்த QPS இல் அதிக தாமதம் OS தேர்வுமுறையால் ஏற்பட்டது. பின்னோக்கிப் பார்த்தால், விவரக்குறிப்பு தாமதத்தைக் கண்டறியவில்லை, ஏனெனில் இது கர்னல் பயன்முறையில் செய்யப்படவில்லை பயனர் முறை. ETW பிடிப்புகள் மூலம் Nagle இன் அல்காரிதத்தை கவனிக்க முடியுமா என்று எனக்குத் தெரியவில்லை, ஆனால் அது சுவாரஸ்யமாக இருக்கும்.

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

அடுத்த முறை வினாடிக்கான கோரிக்கைகளின் எண்ணிக்கை குறையும்போது தாமதம் அதிகரிப்பதைக் காணும் போது, ​​Nagle இன் அல்காரிதம் உங்கள் சந்தேக நபர்களின் பட்டியலில் இருக்க வேண்டும்!

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