LimitNPROC vs TasksMax: OpenVPN அலகு எதைக் கணக்கிடுகிறது

தோல்வியடைந்த OpenVPN தொடக்கம் பெரும்பாலும் வளங்கள் பற்றிய புகாராகவும் ஒரு வரம்பை உயர்த்தும் நல்லெண்ணப் பரிந்துரையாகவும் வருகிறது, அந்தப் பரிந்துரை சுமார் பாதி நிகழ்வுகளில் மட்டுமே வேலை செய்கிறது. அந்தத் தோல்விகளுக்குப் பின்னால் தொடர்பில்லாத இரண்டு எண்ணிகள் உள்ளன. ஒன்று உண்மையான பயனர் ID-க்குச் சொந்தமான பணிகளின் எண்ணிக்கையின் மீதான கர்னல் வரம்பு, செயல்முறை இயக்கப்படும்போது அது மரபுவழியாக வருகிறது. மற்றொன்று cgroup பட்ஜெட், அதை சேவை மேலாளர் ஒரு அலகு மற்றும் அது பிரிக்கும் அனைத்தின் மீதும் பயன்படுத்துகிறார். உண்மையில் இயங்கும் அலகுக்கு ஒவ்வொன்றின் பயனுள்ள மதிப்பைப் படிப்பது ஒரு ஊகத்தை விடக் குறைவான செலவு.

இரண்டு எண்ணிகள், இரண்டு கேள்விகள்

LimitNPROC என்பது systemd பெயரின் கீழ் RLIMIT_NPROC, அதன் கணக்கு அலகு உண்மையான பயனர் ID. அந்தப் பயனருக்குச் சொந்தமான ஒவ்வொரு செயல்முறையும் அதே மொத்தத்தில் கணக்கிடப்படுகிறது, மற்ற அலகுகள், உள்நுழைவு அமர்வு அல்லது திட்டமிடி வேலை தொடங்கிய வேலையும் உட்பட. எனவே இந்த வரம்பு சேவை அலகுக்குள் அமைக்கப்பட்டாலும் ஒவ்வொரு சேவைக்குமான உச்சவரம்பு அல்ல, மேலும் ஒவ்வொரு வாடிக்கையாளருக்கும் ஒரு உதவியாளரைப் பிரிக்கும் சேவை அந்தக் கணக்கின் கீழ் இயங்கும் மற்ற அனைத்துடனும் போட்டியிடுகிறது. அதே பயனரின் கீழ் உள்ள பிஸியான cron வேலை VPN அலகை அது தனியாக ஒருபோதும் கடக்காத கோட்டுக்கு அப்பால் தள்ளலாம்.

TasksMax-க்கு வேறு உரிமையாளர் உண்டு: அலகின் cgroup மீதான pids கட்டுப்படுத்தி, அது செயல்முறைகளை அல்ல, பணிகளை எண்ணுகிறது. இழைகள் பணிகள், எனவே ஒரு இழை போலத் தோன்றும் ஆனால் பணியாளர் குழு கொண்ட டீமன் அதன் செயல்முறை எண்ணிக்கையை விட முதல் பார்வையில் மிகப் பெரியதாகத் தோன்றும் பட்ஜெட்டைச் செலவழிக்கலாம். EffectiveTasksMax பெற்றோர் துண்டுகள் தங்கள் சொல்லைச் சொன்ன பிறகு cgroup படிநிலை உண்மையில் எதை அனுமதிக்கிறது என்பதைத் தெரிவிக்கிறது.

root விதிவிலக்கு பதிலை ஏன் மாற்றுகிறது

கர்னல் CAP_SYS_RESOURCE அல்லது CAP_SYS_ADMIN கொண்ட செயல்முறைக்கு RLIMIT_NPROC-ஐப் பயன்படுத்துவதில்லை, அதனால் சலுகைகளை விட்டுக்கொடுக்காமல் root ஆக இயங்கும் அலகு அந்த அமைப்பால் நடைமுறையில் வரம்பற்றதாக உள்ளது. இந்த ஒரே விதிவிலக்கே மக்கள் பரிமாறிக்கொள்ளும் முரணான ஆலோசனையை விளக்குகிறது: LimitNPROC-ஐ உயர்த்துவது சலுகைகளை விட்டுக்கொடுத்த வரிசைப்படுத்தலைச் சரிசெய்யும், சலுகைகளைத் தக்கவைத்துக்கொண்ட ஒன்றுக்கு எதுவும் செய்யாது. அந்த அமைப்புக்குப் புகழோ குற்றமோ சொல்வதற்கு முன் User= மற்றும் டீமன் தொடங்கிய பிறகு அடையாளத்தை மாற்றுகிறதா என்பதைச் சரிபார்க்கவும். சலுகைகள் கொண்ட அலகு பின்னர் சலுகையற்ற கணக்குக்கு மாறினால் மாற்றத்தின் அந்தக் கணத்தில் மீண்டும் வரம்புக்குக் கீழ் வருகிறது, இது தோல்வியின் காலவரிசையையும் படிக்கத் தகுந்ததாக்குகிறது.

தோல்வியின் நிலை இதை மேலும் குறுக்குகிறது. இயக்கத் தயாரிப்பின்போது மறுப்பு, டீமன் தானே தெரிவிக்கும் பிரிப்புப் பிழை, மற்றும் cgroup-க்குள் நிராகரிக்கப்பட்ட பணி உருவாக்கம் ஆகியவை வெவ்வேறு journal வரிகளைத் தருகின்றன, அவற்றில் ஒன்றுக்கு மட்டுமே பெரிய பட்ஜெட் பதிலளிக்கிறது.

பயனுள்ள மதிப்புகளைப் படியுங்கள், ஷெல்லின் மதிப்புகளை அல்ல

ஊடாடும் ஷெல்லின் ulimit -u அந்த ஷெல்லை விவரிக்கிறது. சேவை மேலாளர் டீமனுக்கு என்ன கொடுத்தார் என்பதை அது விவரிக்கவில்லை, cgroup கணக்கியல் பற்றி எதுவும் சொல்லவில்லை. அதற்குப் பதிலாக அலகைக் கேளுங்கள், வழிகாட்டியின் எடுத்துக்காட்டுக்குப் பதிலாக ஹோஸ்ட்டில் உள்ள நிகழ்வுப் பெயரைப் பயன்படுத்தி.

systemctl show [email protected] -p User -p LimitNPROC -p TasksCurrent -p TasksMax -p EffectiveTasksMax
cat /proc/$(systemctl show -p MainPID --value [email protected])/limits | grep -i processes

கொள்கலனுக்குள் பதிலுக்கு இன்னும் இரண்டு வாசிப்புகள் தேவை, ஏனெனில் infinity-இன் உள் மதிப்பு விருந்தினரின் பார்வையை மட்டுமே விவரிக்கிறது. ஹோஸ்ட்டின் உரிமையாளரிடம் கொள்கலனின் சொந்த pids உச்சவரம்பைக் கேளுங்கள், உள் சேவை மேலாளர் அந்தக் கட்டுப்படுத்தியை ஒப்படைக்க முடியுமா என்பதை உறுதிப்படுத்துங்கள். உள்ளமைந்த அலகு அதன் பெற்றோர் cgroup ஒருபோதும் கொடாத பட்ஜெட்டை வைத்திருக்க முடியாது.

சரிசெய்தலின் அளவை அளந்து சுமையின் கீழ் நிரூபியுங்கள்

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

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

sudo systemctl daemon-reload
sudo systemctl restart [email protected]
systemctl show [email protected] -p TasksCurrent -p EffectiveTasksMax
sudo journalctl -u [email protected] -b --no-pager | tail -n 20

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