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-ഉം ആണ്. മാറ്റത്തോടൊപ്പം മുൻപിന്റെയും ശേഷമുള്ള സംഖ്യകളും സൂക്ഷിക്കുക, അടുത്ത അന്വേഷണം അതേ ഉപദേശത്തിൽ നിന്നല്ല, ഒരു അളവിൽ നിന്ന് തുടങ്ങട്ടെ. സംഖ്യ ഇപ്പോഴും പരിധിയിൽ എത്തുന്നുവെങ്കിൽ കണക്കാണ് തെറ്റായത്, പരിധി യാദൃശ്ചികമായി വളരെ ചെറുതായതല്ല, അടുത്ത പുനരാരംഭത്തിന് മുമ്പ് ആ വ്യത്യാസം അറിയേണ്ടതുണ്ട്.