SRE: செயல்திறன் பகுப்பாய்வு. Go இல் எளிய இணைய சேவையகத்தைப் பயன்படுத்தி அமைவு முறை

செயல்திறன் பகுப்பாய்வு மற்றும் ட்யூனிங் என்பது வாடிக்கையாளர்களுக்கான செயல்திறன் இணக்கத்தை சரிபார்க்க ஒரு சக்திவாய்ந்த கருவியாகும்.

ட்யூனிங் சோதனைகளைச் சோதிப்பதில் ஒரு விஞ்ஞான அணுகுமுறையைப் பயன்படுத்துவதன் மூலம் ஒரு திட்டத்தில் உள்ள இடையூறுகளைச் சரிபார்க்க செயல்திறன் பகுப்பாய்வு பயன்படுத்தப்படலாம். இந்த கட்டுரை செயல்திறன் பகுப்பாய்வு மற்றும் டியூனிங்கிற்கான பொதுவான அணுகுமுறையை வரையறுக்கிறது, உதாரணமாக Go webserver ஐப் பயன்படுத்துகிறது.

Go என்பது இங்கே சிறப்பாக உள்ளது, ஏனெனில் அதில் சுயவிவரக் கருவிகள் உள்ளன pprof நிலையான நூலகத்தில்.

மூலோபாயம்

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

• தேர்வுமுறை எல்லைகளை (தேவைகள்) தீர்மானிக்கிறோம்;
• கணினிக்கான பரிவர்த்தனை சுமையை நாங்கள் கணக்கிடுகிறோம்;
• நாங்கள் சோதனை செய்கிறோம் (தரவை உருவாக்கவும்);
• நாங்கள் கவனிக்கிறோம்;
• நாங்கள் பகுப்பாய்வு செய்கிறோம் - அனைத்து தேவைகளும் பூர்த்தி செய்யப்பட்டதா?
• நாங்கள் அதை அறிவியல் ரீதியாக அமைத்து, ஒரு கருதுகோளை உருவாக்குகிறோம்;
• இந்தக் கருதுகோளைச் சோதிக்க நாங்கள் ஒரு பரிசோதனையைச் செய்கிறோம்.

எளிய HTTP சர்வர் கட்டமைப்பு

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

பகுப்பாய்வு செய்யப்படும் பயன்பாடு ஒரு HTTP சேவையகமாகும், இது ஒவ்வொரு கோரிக்கைக்கும் Postgresql வாக்கெடுப்பு ஆகும். கூடுதலாக, பயன்பாடு மற்றும் கணினி அளவீடுகளை சேகரித்து காட்டுவதற்கு Prometheus, node_exporter மற்றும் Grafana உள்ளது.

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

இலக்குகளை வரையறுத்தல்

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

В Google SRE புத்தகம் தேர்வு மற்றும் மாடலிங் முறைகள் விரிவாக விவாதிக்கப்படுகின்றன. அதையே செய்து மாதிரிகளை உருவாக்குவோம்:

• தாமதம்: 99% கோரிக்கைகள் 60msக்கும் குறைவாக முடிக்கப்பட வேண்டும்;
• செலவு: நியாயமான முறையில் சாத்தியம் என்று நாங்கள் நினைக்கும் குறைந்தபட்ச தொகையை சேவை பயன்படுத்த வேண்டும். இதைச் செய்ய, செயல்திறனை அதிகரிக்கிறோம்;
• திறன் திட்டமிடல்: ஒட்டுமொத்த அளவிடுதல் செயல்பாடு உட்பட, பயன்பாட்டின் எத்தனை நிகழ்வுகள் இயக்கப்பட வேண்டும் என்பதைப் புரிந்துகொள்வது மற்றும் ஆவணப்படுத்துவது அவசியம் மற்றும் ஆரம்ப சுமை மற்றும் வழங்கல் தேவைகளைப் பூர்த்தி செய்ய எத்தனை நிகழ்வுகள் தேவைப்படும் பணிநீக்கம் n+1.

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

சோதனை சூழலை அமைத்தல்

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

பரிவர்த்தனை சுமை

இந்த சூழல் பயன்படுத்துகிறது Vegeta நிறுத்தப்படும் வரை தனிப்பயன் HTTP கோரிக்கை விகிதத்தை உருவாக்க:

$ make load-test LOAD_TEST_RATE=50
echo "POST http://localhost:8080" | vegeta attack -body tests/fixtures/age_no_match.json -rate=50 -duration=0 | tee results.bin | vegeta report

பார்த்து

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

விவரக்குறிப்பு

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

வீணான CPU நேரம் மற்றும் தேவையற்ற வேலைகள் பற்றிய நுண்ணறிவைப் பெற பகுப்பாய்வின் போது இந்தத் தரவைப் பயன்படுத்தலாம். Go (pprof) ஆனது சுயவிவரங்களை உருவாக்கி, நிலையான கருவிகளின் தொகுப்பைப் பயன்படுத்தி அவற்றை சுடர் வரைபடங்களாகக் காட்சிப்படுத்தலாம். அவற்றின் பயன்பாடு மற்றும் அமைவு வழிகாட்டி பற்றி பின்னர் கட்டுரையில் பேசுவேன்.

செயல்படுத்தல், கவனிப்பு, பகுப்பாய்வு.

ஒரு பரிசோதனை செய்வோம். செயல்திறனில் திருப்தி அடையும் வரை நாங்கள் நிகழ்த்துவோம், கவனிப்போம் மற்றும் பகுப்பாய்வு செய்வோம். முதல் அவதானிப்புகளின் முடிவுகளைப் பெறுவதற்குப் பயன்படுத்த, தன்னிச்சையாக குறைந்த சுமை மதிப்பைத் தேர்ந்தெடுப்போம். ஒவ்வொரு அடுத்த கட்டத்திலும், சில மாறுபாடுகளுடன் தேர்ந்தெடுக்கப்பட்ட ஒரு குறிப்பிட்ட அளவிடுதல் காரணி மூலம் சுமைகளை அதிகரிப்போம். ஒவ்வொரு சுமை சோதனை ஓட்டமும் சரிசெய்யப்பட்ட கோரிக்கைகளின் எண்ணிக்கையுடன் செய்யப்படுகிறது: make load-test LOAD_TEST_RATE=X.

வினாடிக்கு 50 கோரிக்கைகள்

முதல் இரண்டு வரைபடங்களுக்கு கவனம் செலுத்துங்கள். மேல் இடதுபுறம் எங்கள் விண்ணப்பம் ஒரு வினாடிக்கு 50 கோரிக்கைகளைச் செயலாக்குகிறது (அது நினைக்கிறது) மற்றும் மேல் வலதுபுறம் ஒவ்வொரு கோரிக்கையின் கால அளவையும் காட்டுகிறது. இரண்டு அளவுருக்களும் நாம் நமது செயல்திறன் எல்லைக்குள் இருக்கிறோமா இல்லையா என்பதைப் பார்க்கவும் பகுப்பாய்வு செய்யவும் உதவுகின்றன. வரைபடத்தில் சிவப்பு கோடு HTTP கோரிக்கை தாமதம் SLO 60ms இல் காட்டுகிறது. எங்கள் அதிகபட்ச மறுமொழி நேரத்திற்கு நாங்கள் மிகவும் குறைவாக இருப்பதை வரி காட்டுகிறது.

செலவு பக்கத்தைப் பார்ப்போம்:

வினாடிக்கு 10000 கோரிக்கைகள் / ஒரு சர்வருக்கு 50 கோரிக்கைகள் = 200 சர்வர்கள் + 1

இந்த எண்ணிக்கையை நாம் இன்னும் மேம்படுத்தலாம்.

வினாடிக்கு 500 கோரிக்கைகள்

வினாடிக்கு 500 கோரிக்கைகளை ஏற்றும்போது மிகவும் சுவாரஸ்யமான விஷயங்கள் நடக்கத் தொடங்குகின்றன:

மீண்டும், மேல் இடது வரைபடத்தில், பயன்பாடு சாதாரண சுமையைப் பதிவு செய்வதைக் காணலாம். இது அவ்வாறு இல்லையென்றால், பயன்பாடு இயங்கும் சேவையகத்தில் சிக்கல் உள்ளது. மறுமொழி தாமத வரைபடம் மேல் வலதுபுறத்தில் அமைந்துள்ளது, இது ஒரு வினாடிக்கு 500 கோரிக்கைகள் 25-40ms பதில் தாமதத்தை ஏற்படுத்துகிறது என்பதைக் காட்டுகிறது. மேலே தேர்ந்தெடுக்கப்பட்ட 99ms SLO உடன் 60வது சதவிகிதம் இன்னும் நன்றாகப் பொருந்துகிறது.

செலவு அடிப்படையில்:

வினாடிக்கு 10000 கோரிக்கைகள் / ஒரு சர்வருக்கு 500 கோரிக்கைகள் = 20 சர்வர்கள் + 1

எல்லாவற்றையும் இன்னும் மேம்படுத்தலாம்.

வினாடிக்கு 1000 கோரிக்கைகள்

சிறப்பான துவக்கம்! வினாடிக்கு 1000 கோரிக்கைகளைச் செயல்படுத்தியதாக பயன்பாடு காட்டுகிறது, ஆனால் தாமத வரம்பு SLO ஆல் மீறப்பட்டது. இது மேல் வலது வரைபடத்தில் வரி p99 இல் காணலாம். p100 வரி மிக அதிகமாக இருந்தாலும், உண்மையான தாமதங்கள் அதிகபட்சம் 60ms ஐ விட அதிகமாக உள்ளது. அப்ளிகேஷன் உண்மையில் என்ன செய்கிறது என்பதைக் கண்டறிய விவரக்குறிப்பிற்குள் நுழைவோம்.

விவரக்குறிப்பு

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

$ curl http://localhost:8080/debug/pprof/profile?seconds=29 > cpu.1000_reqs_sec_no_optimizations.prof

முடிவுகளை இப்படிக் காட்டலாம்:

$ go tool pprof -http=:12345 cpu.1000_reqs_sec_no_optimizations.prof

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

X அச்சு என்பது ஸ்டாக் சுயவிவர மக்கள்தொகை, அகர வரிசைப்படி வரிசைப்படுத்தப்பட்டுள்ளது (இது நேரம் அல்ல), Y அச்சு அடுக்கின் ஆழத்தைக் காட்டுகிறது, [மேலே] பூஜ்ஜியத்திலிருந்து கணக்கிடப்படுகிறது. ஒவ்வொரு செவ்வகமும் ஒரு அடுக்கு சட்டமாகும். பரந்த சட்டகம், அடிக்கடி அது அடுக்குகளில் உள்ளது. மேலே உள்ளவை CPU இல் இயங்குகின்றன, மேலும் கீழே உள்ளவை குழந்தை கூறுகள். நிறங்கள் பொதுவாக எதையும் குறிக்காது, ஆனால் பிரேம்களை வேறுபடுத்த சீரற்ற முறையில் தேர்ந்தெடுக்கப்படுகின்றன.

பகுப்பாய்வு - கருதுகோள்

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

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

வரைபடத்தில் ஒரு செயல்பாட்டின் பெயரின் மீது கர்சரை நகர்த்தினால், பிழைத்திருத்தத்தின் போது அடுக்கில் இருந்த மொத்த நேரம் காட்டப்படும். HTTPServe செயல்பாடு 65% நேரம் இருந்தது, மற்ற இயக்க நேர செயல்பாடுகள் runtime.mcall, mstart и gc, மீதமுள்ள நேரத்தை எடுத்துக் கொண்டது. வேடிக்கையான உண்மை: மொத்த நேரத்தின் 5% DNS வினவல்களுக்காக செலவிடப்படுகிறது:

நிரல் தேடும் முகவரிகள் Postgresql க்கு சொந்தமானது. கிளிக் செய்யவும் FindByAge:

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

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

பயன்பாட்டை அமைத்தல் - பரிசோதனை

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

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)

if err != nil {
   return nil, err
}

செயல்படுத்தல், கவனிப்பு, பகுப்பாய்வு

வினாடிக்கு 1000 கோரிக்கைகளுடன் சோதனையை மறுதொடக்கம் செய்த பிறகு, p99 இன் தாமத நிலைகள் 60ms SLO உடன் இயல்பு நிலைக்குத் திரும்பியது தெளிவாகிறது!

என்ன செலவு?

வினாடிக்கு 10000 கோரிக்கைகள் / ஒரு சர்வருக்கு 1000 கோரிக்கைகள் = 10 சர்வர்கள் + 1

இன்னும் சிறப்பாக செய்வோம்!

வினாடிக்கு 2000 கோரிக்கைகள்

சுமையை இரட்டிப்பாக்குவது அதையே காட்டுகிறது, மேல் இடது வரைபடம் வினாடிக்கு 2000 கோரிக்கைகளைச் செயலாக்குகிறது, p100 60ms ஐ விடக் குறைவாக உள்ளது, p99 SLO ஐ திருப்திப்படுத்துகிறது.

செலவு அடிப்படையில்:

வினாடிக்கு 10000 கோரிக்கைகள் / ஒரு சர்வருக்கு 2000 கோரிக்கைகள் = 5 சர்வர்கள் + 1

வினாடிக்கு 3000 கோரிக்கைகள்

இங்கே விண்ணப்பமானது 3000msக்கும் குறைவான p99 தாமதத்துடன் 60 கோரிக்கைகளைச் செயல்படுத்த முடியும். SLO மீறப்படவில்லை, மேலும் செலவு பின்வருமாறு ஏற்றுக்கொள்ளப்படுகிறது:

வினாடிக்கு 10000 கோரிக்கைகள் / ஒரு சர்வருக்கு 3000 கோரிக்கைகள் = 4 சர்வர்கள் + 1 (ஆசிரியர் சுற்றி வளைத்துள்ளார், தோராயமாக மொழிபெயர்ப்பாளர்)

மற்றொரு சுற்று பகுப்பாய்வு முயற்சி செய்யலாம்.

பகுப்பாய்வு - கருதுகோள்

ஒரு வினாடிக்கு 3000 கோரிக்கைகளில் பயன்பாட்டை பிழைத்திருத்தத்தின் முடிவுகளை நாங்கள் சேகரித்து காண்பிக்கிறோம்:

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

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

பயன்பாட்டை அமைத்தல் - பரிசோதனை

நிறுவ முயற்சிக்கிறது MaxIdleConns குளத்தின் அளவிற்கு சமம் (மேலும் விவரிக்கப்பட்டுள்ளது இங்கே):

db, err := sql.Open("postgres", dbConnectionString)
db.SetMaxOpenConns(8)
db.SetMaxIdleConns(8)
if err != nil {
   return nil, err
}

செயல்படுத்தல், கவனிப்பு, பகுப்பாய்வு

வினாடிக்கு 3000 கோரிக்கைகள்

p99 என்பது 60msக்கும் குறைவான p100 இல் உள்ளது!

சுடர் வரைபடத்தைச் சரிபார்ப்பது இணைப்பு இனி கவனிக்கப்படாது என்பதைக் காட்டுகிறது! இன்னும் விரிவாகப் பார்ப்போம் pg(*conn).query - இங்கே இணைப்பு நிறுவப்பட்டதை நாங்கள் கவனிக்கவில்லை.

முடிவுக்கு

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

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