குபெர்னெட்டஸில் CPU வரம்புகள் மற்றும் ஆக்கிரமிப்பு த்ரோட்லிங்

குறிப்பு. மொழிபெயர்: ஓமியோவின் இந்த கண் திறக்கும் வரலாறு—ஐரோப்பிய பயணத் திரட்டி— வாசகர்களை அடிப்படைக் கோட்பாட்டிலிருந்து குபெர்னெட்டஸ் உள்ளமைவின் வசீகரமான நடைமுறை நுணுக்கங்களுக்கு அழைத்துச் செல்கிறது. இதுபோன்ற நிகழ்வுகளுடன் பழகுவது உங்கள் எல்லைகளை விரிவுபடுத்துவது மட்டுமல்லாமல், அற்பமான சிக்கல்களைத் தடுக்கவும் உதவுகிறது.

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

டிஎல்; டி.ஆர்:
நீங்கள் CFS கோட்டா பிழையுடன் Linux கர்னலின் பதிப்பைப் பயன்படுத்தினால், Kubernetes இல் CPU வரம்புகளை முடக்க பரிந்துரைக்கிறோம் (அல்லது Kubelet இல் CFS ஒதுக்கீட்டை முடக்கவும்). மையத்தில் கிடைக்கிறது தீவிர மற்றும் நன்கு அறியப்பட்ட அதிகப்படியான த்ரோட்லிங் மற்றும் தாமதத்திற்கு வழிவகுக்கும் ஒரு பிழை.

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

கட்டுரையின் சுருக்கம்:

• கொள்கலன்கள் மற்றும் குபெர்னெட்ஸ் பற்றி சில வார்த்தைகள்;
• CPU கோரிக்கைகள் மற்றும் வரம்புகள் எவ்வாறு செயல்படுத்தப்படுகின்றன;
• மல்டி-கோர் சூழல்களில் CPU வரம்பு எவ்வாறு செயல்படுகிறது;
• CPU த்ரோட்டிங்கை எவ்வாறு கண்காணிப்பது;
• சிக்கல் தீர்வு மற்றும் நுணுக்கங்கள்.

கொள்கலன்கள் மற்றும் குபெர்னெட்ஸ் பற்றி சில வார்த்தைகள்

குபெர்னெட்டஸ் என்பது உள்கட்டமைப்பு உலகில் நவீன தரநிலையாகும். அதன் முக்கிய பணி கொள்கலன் ஆர்கெஸ்ட்ரேஷன் ஆகும்.

கொள்கலன்கள்

கடந்த காலத்தில், சர்வர்களில் இயங்குவதற்கு Java JARs/WARs, Python Eggs அல்லது executables போன்ற கலைப்பொருட்களை உருவாக்க வேண்டியிருந்தது. இருப்பினும், அவை செயல்பட, கூடுதல் வேலை செய்ய வேண்டியிருந்தது: இயக்க நேர சூழலை (ஜாவா / பைதான்) நிறுவுதல், தேவையான கோப்புகளை சரியான இடங்களில் வைப்பது, இயக்க முறைமையின் குறிப்பிட்ட பதிப்போடு இணக்கத்தை உறுதி செய்தல் போன்றவை. வேறு வார்த்தைகளில் கூறுவதானால், உள்ளமைவு நிர்வாகத்தில் கவனமாக கவனம் செலுத்தப்பட வேண்டும் (இது பெரும்பாலும் டெவலப்பர்கள் மற்றும் கணினி நிர்வாகிகளுக்கு இடையே சர்ச்சையை ஏற்படுத்துகிறது).

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

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

Kubernetes

முன்பு கூறியது போல், குபெர்னெட்ஸ் ஒரு கொள்கலன் இசைக்குழு. இது இப்படிச் செயல்படுகிறது: நீங்கள் அதற்கு இயந்திரங்களின் தொகுப்பைக் கொடுத்து, பின்னர் கூறுங்கள்: "ஏய், குபெர்னெட்டஸ், 2 செயலிகள் மற்றும் ஒவ்வொன்றும் 3 ஜிபி நினைவகம் கொண்ட எனது கொள்கலனின் பத்து நிகழ்வுகளை சுழற்றுவோம், அவற்றை தொடர்ந்து இயக்குவோம்!" மீதியை குபர்னெட்ஸ் பார்த்துக் கொள்வார். இது இலவச திறனைக் கண்டறியும், கொள்கலன்களைத் தொடங்கும் மற்றும் தேவைப்பட்டால் அவற்றை மறுதொடக்கம் செய்யும், பதிப்புகளை மாற்றும்போது புதுப்பிப்பை வெளியிடும். அடிப்படையில், குபெர்னெட்டஸ் உங்களை வன்பொருள் கூறுகளை சுருக்கவும், பயன்பாடுகளை வரிசைப்படுத்தவும் இயக்கவும் பொருத்தமான பல்வேறு அமைப்புகளை உருவாக்குகிறது.

சாதாரண மனிதனின் பார்வையில் இருந்து குபர்னெட்ஸ்

குபெர்னெட்டஸில் உள்ள கோரிக்கைகள் மற்றும் வரம்புகள் என்ன

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

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

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

கோரிக்கைகளும் வரம்புகளும் குபெர்னெட்டஸில் எவ்வாறு செயல்படுத்தப்படுகின்றன

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

CPU கோரிக்கை

CPU கோரிக்கை எவ்வாறு செயல்படுத்தப்படுகிறது

எளிமைக்காக, உதாரணமாக 4-கோர் CPU கொண்ட இயந்திரத்தைப் பயன்படுத்தும் செயல்முறையைப் பார்ப்போம்.

வளங்களின் (நினைவகம் மற்றும் செயலி) ஒதுக்கீட்டைக் கட்டுப்படுத்த K8s ஒரு கட்டுப்பாட்டு குழு பொறிமுறையை (cgroups) பயன்படுத்துகிறது. அதற்கு ஒரு படிநிலை மாதிரி உள்ளது: குழந்தை பெற்றோர் குழுவின் வரம்புகளைப் பெறுகிறது. விநியோக விவரங்கள் மெய்நிகர் கோப்பு முறைமையில் சேமிக்கப்படும் (/sys/fs/cgroup) ஒரு செயலியின் விஷயத்தில் இது /sys/fs/cgroup/cpu,cpuacct/*.

K8s கோப்பைப் பயன்படுத்துகிறது cpu.share செயலி வளங்களை ஒதுக்க. எங்கள் விஷயத்தில், ரூட் cgroup CPU வளங்களின் 4096 பங்குகளைப் பெறுகிறது - கிடைக்கக்கூடிய செயலி சக்தியில் 100% (1 கோர் = 1024; இது ஒரு நிலையான மதிப்பு). ரூட் குழுவில் பதிவுசெய்யப்பட்ட சந்ததியினரின் பங்குகளைப் பொறுத்து வளங்களை விகிதாசாரமாக விநியோகிக்கிறது cpu.share, மற்றும் அவர்கள், தங்கள் சந்ததியினரிடமும் அவ்வாறே செய்கிறார்கள். ஒரு பொதுவான குபெர்னெட்டஸ் முனையில், ரூட் cgroup மூன்று குழந்தைகளைக் கொண்டுள்ளது: system.slice, user.slice и kubepods. முதல் இரண்டு துணைக்குழுக்கள் முக்கியமான கணினி சுமைகள் மற்றும் K8 களுக்கு வெளியே உள்ள பயனர் நிரல்களுக்கு இடையில் வளங்களை விநியோகிக்கப் பயன்படுத்தப்படுகின்றன. கடைசியாக - kubepods - காய்களுக்கு இடையில் வளங்களை விநியோகிக்க குபெர்னெட்டஸால் உருவாக்கப்பட்டது.

மேலே உள்ள வரைபடம் முதல் மற்றும் இரண்டாவது துணைக்குழுக்கள் ஒவ்வொன்றையும் பெற்றதைக் காட்டுகிறது 1024 பங்குகள், kuberpod துணைக்குழுவுக்கு ஒதுக்கப்பட்டது 4096 பங்குகள் இது எப்படி சாத்தியம்: எல்லாவற்றிற்கும் மேலாக, ரூட் குழுவிற்கு மட்டுமே அணுகல் உள்ளது 4096 பங்குகள், மற்றும் அவரது சந்ததியினரின் பங்குகளின் கூட்டுத்தொகை இந்த எண்ணிக்கையை கணிசமாக மீறுகிறது (6144)? புள்ளி என்னவென்றால், மதிப்பு தர்க்கரீதியான அர்த்தத்தை அளிக்கிறது, எனவே லினக்ஸ் திட்டமிடுபவர் (CFS) CPU ஆதாரங்களை விகிதாசாரமாக ஒதுக்குவதற்குப் பயன்படுத்துகிறது. எங்கள் விஷயத்தில், முதல் இரண்டு குழுக்கள் பெறுகின்றன 680 உண்மையான பங்குகள் (16,6 இல் 4096%), மற்றும் kubepod மீதமுள்ளவற்றைப் பெறுகிறது 2736 பங்குகள் வேலையில்லா நேரத்தில், முதல் இரண்டு குழுக்கள் ஒதுக்கப்பட்ட ஆதாரங்களைப் பயன்படுத்தாது.

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

இந்த பொறிமுறையானது செயலி சக்தியின் நியாயமான விநியோகத்தை உறுதிசெய்கிறது மற்றும் பிறரிடமிருந்து வளங்களை யாரும் "திருடவில்லை" என்பதை உறுதிப்படுத்துகிறது.

CPU வரம்பு

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

K8s ஈடுபடுகிறது CFS ஒதுக்கீடு பொறிமுறை வரம்புகளை செயல்படுத்த. அவற்றின் அமைப்புகள் கோப்புகளில் குறிப்பிடப்பட்டுள்ளன cfs_period_us и cfs_quota_us cgroup கோப்பகத்தில் (கோப்பும் அங்கு அமைந்துள்ளது cpu.share).

போலல்லாமல் cpu.share, ஒதுக்கீடு அடிப்படையாக கொண்டது கால கட்டம், மற்றும் கிடைக்கக்கூடிய செயலி சக்தியில் இல்லை. cfs_period_us கால அளவு (சகாப்தம்) குறிப்பிடுகிறது - இது எப்போதும் 100000 μs (100 ms) ஆகும். K8s இல் இந்த மதிப்பை மாற்ற ஒரு விருப்பம் உள்ளது, ஆனால் அது இப்போது ஆல்பாவில் மட்டுமே கிடைக்கிறது. பயன்படுத்திய ஒதுக்கீட்டை மறுதொடக்கம் செய்ய திட்டமிடுபவர் சகாப்தத்தைப் பயன்படுத்துகிறார். இரண்டாவது கோப்பு cfs_quota_us, ஒவ்வொரு சகாப்தத்திலும் கிடைக்கும் நேரத்தை (கோட்டா) குறிப்பிடுகிறது. இது மைக்ரோ விநாடிகளிலும் குறிப்பிடப்பட்டுள்ளது என்பதை நினைவில் கொள்க. ஒதுக்கீடு சகாப்தத்தின் நீளத்தை விட அதிகமாக இருக்கலாம்; வேறு வார்த்தைகளில் கூறுவதானால், இது 100 ms ஐ விட அதிகமாக இருக்கலாம்.

16-கோர் இயந்திரங்களில் இரண்டு காட்சிகளைப் பார்ப்போம் (ஓமியோவில் நாம் வைத்திருக்கும் மிகவும் பொதுவான வகை கணினி):

காட்சி 1: 2 இழைகள் மற்றும் 200 எம்எஸ் வரம்பு. த்ரோட்லிங் இல்லை

காட்சி 2: 10 இழைகள் மற்றும் 200 எம்எஸ் வரம்பு. 20 எம்எஸ்க்குப் பிறகு த்ரோட்லிங் தொடங்குகிறது, செயலி ஆதாரங்களுக்கான அணுகல் மற்றொரு 80 எம்எஸ்க்குப் பிறகு மீண்டும் தொடங்கப்படும்

நீங்கள் CPU வரம்பை அமைக்கிறீர்கள் என்று வைத்துக்கொள்வோம் 2 கர்னல்கள்; குபெர்னெட்ஸ் இந்த மதிப்பை 200 msக்கு மொழிபெயர்ப்பார். இதன் பொருள் கொள்கலன் அதிகபட்சமாக 200ms CPU நேரத்தை த்ரோட்டில் இல்லாமல் பயன்படுத்தலாம்.

இங்குதான் வேடிக்கை தொடங்குகிறது. மேலே குறிப்பிட்டுள்ளபடி, கிடைக்கும் ஒதுக்கீடு 200 எம்.எஸ். நீங்கள் இணையாக வேலை செய்தால் பத்து 12-கோர் இயந்திரத்தில் உள்ள த்ரெட்கள் (காட்சி 2க்கான விளக்கத்தைப் பார்க்கவும்), மற்ற எல்லா காய்களும் செயலற்ற நிலையில் இருக்கும்போது, ​​ஒதுக்கீடு வெறும் 20 எம்எஸ் (10 * 20 எம்எஸ் = 200 எம்எஸ் என்பதால்) தீர்ந்துவிடும், மேலும் இந்த பாட்டின் அனைத்து த்ரெட்களும் தொங்கும் » (த்ரோட்டில்) அடுத்த 80 msக்கு. ஏற்கனவே குறிப்பிட்டது திட்டமிடல் பிழை, இதன் காரணமாக அதிகப்படியான த்ரோட்லிங் ஏற்படுகிறது மற்றும் கன்டெய்னரால் ஏற்கனவே உள்ள ஒதுக்கீட்டை கூட பூர்த்தி செய்ய முடியாது.

காய்களில் த்ரோட்டிங்கை எவ்வாறு மதிப்பிடுவது?

பாடில் உள்நுழைந்து இயக்கவும் cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - திட்டமிடல் காலங்களின் மொத்த எண்ணிக்கை;
• nr_throttled - கலவையில் த்ரோட்டில் காலங்களின் எண்ணிக்கை nr_periods;
• throttled_time - நானோ வினாடிகளில் ஒட்டுமொத்த த்ரோட்டில்ட் நேரம்.

உண்மையில் என்ன நடக்கிறது?

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

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

முடிவு மற்றும் விளைவுகள்

இங்கே எல்லாம் எளிது. CPU வரம்புகளை கைவிட்டு, OS கர்னலை கிளஸ்டர்களில் உள்ள சமீபத்திய பதிப்பிற்கு புதுப்பிக்கத் தொடங்கினோம், அதில் பிழை சரி செய்யப்பட்டது. எங்கள் சேவைகளில் பிழைகளின் எண்ணிக்கை (HTTP 5xx) உடனடியாக கணிசமாகக் குறைந்தது:

HTTP 5xx பிழைகள்

ஒரு முக்கியமான சேவைக்கான HTTP 5xx பிழைகள்

மறுமொழி நேரம் p95

முக்கியமான சேவை கோரிக்கை தாமதம், 95வது சதவீதம்

இயக்க செலவுகள்

செலவழித்த நேரங்களின் எண்ணிக்கை

பிடிப்பது என்ன?

கட்டுரையின் தொடக்கத்தில் கூறியது போல்:

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

இதோ கேட்ச். ஒரு கவனக்குறைவான கொள்கலன் ஒரு கணினியில் கிடைக்கக்கூடிய அனைத்து CPU வளங்களையும் தின்றுவிடும். உங்களிடம் ஸ்மார்ட் அப்ளிகேஷன் ஸ்டாக் இருந்தால் (உதாரணமாக, ஜேவிஎம், கோ, நோட் விஎம் சரியாக உள்ளமைக்கப்பட்டுள்ளது), இது ஒரு பிரச்சனையல்ல: நீங்கள் நீண்ட நேரம் இதுபோன்ற நிலைமைகளில் வேலை செய்யலாம். ஆனால் பயன்பாடுகள் மோசமாக உகந்ததாக இருந்தால் அல்லது மேம்படுத்தப்படவில்லை என்றால் (FROM java:latest), நிலைமை கட்டுப்பாட்டை மீறலாம். Omio இல், முக்கிய மொழி அடுக்கிற்கான போதுமான இயல்புநிலை அமைப்புகளுடன் தானியங்கு அடிப்படை Dockerfiles உள்ளது, எனவே இந்தச் சிக்கல் இல்லை.

அளவீடுகளை கண்காணிக்க பரிந்துரைக்கிறோம் உபயோகம் (பயன்பாடு, செறிவு மற்றும் பிழைகள்), API தாமதங்கள் மற்றும் பிழை விகிதங்கள். முடிவுகள் எதிர்பார்ப்புகளை பூர்த்தி செய்வதை உறுதி செய்யவும்.

குறிப்புகள்

இது எங்கள் கதை. என்ன நடக்கிறது என்பதைப் புரிந்துகொள்ள பின்வரும் பொருட்கள் பெரிதும் உதவியது:

• kernel.org → CFS திட்டமிடுபவர்;
• kernel.org → CFS அலைவரிசை கட்டுப்பாடு;
• லினக்ஸ் கொள்கலன் திட்டமிடலைப் புரிந்துகொள்வது;
• லினக்ஸ் கண்டெய்னர்கள் பற்றி நீங்கள் தெரிந்து கொள்ள வேண்டிய அனைத்தும், பகுதி I: லினக்ஸ் கட்டுப்பாட்டு குழுக்கள் மற்றும் செயல்முறை தனிமைப்படுத்தல்;
• குபெர்னெட்டஸ் தோல்விக் கதைகள் - "cpu throttling" ஐப் பார்க்கவும்.

குபெர்னெட்ஸ் பிழை அறிக்கைகள்:

• #51135: உத்தரவாதமான காய்களுக்கு CPU வரம்புகளை அமைப்பதைத் தவிர்க்கவும்;
• #67577: CFS ஒதுக்கீடுகள் தேவையற்ற த்ரோட்டிலிங்கிற்கு வழிவகுக்கும்;
• அதிகப்படியான ஆக்கிரமிப்பு CFS.

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

மொழிபெயர்ப்பாளரிடமிருந்து பி.எஸ்

எங்கள் வலைப்பதிவிலும் படிக்கவும்:

• «குபெர்னெட்டஸில் ஆட்டோஸ்கேலிங் மற்றும் வள மேலாண்மை (கண்ணோட்டம் மற்றும் வீடியோ அறிக்கை)";
• «குபெர்னெட்டஸில் CPU மேலாளர் எவ்வாறு வேலை செய்கிறார்";
• «நீங்கள் kubectl ரன் இயக்கும்போது குபெர்னெட்ஸில் என்ன நடக்கிறது? பகுதி 2".

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