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. మార్పుతో పాటు ముందు మరియు తర్వాత సంఖ్యలను ఉంచండి, తదుపరి పరిశోధన అదే సలహా నుంచి కాదు, ఒక కొలత నుంచి ప్రారంభం కావాలి. సంఖ్య ఇప్పటికీ గరిష్ఠాన్ని చేరుకుంటే, లెక్కే తప్పు, పరిమితి యాదృచ్ఛికంగా చాలా చిన్నది కాదు, మరియు తదుపరి పునఃప్రారంభానికి ముందు ఆ తేడా తెలియడం మంచిది.