LimitNPROC વિરુદ્ધ TasksMax: એક OpenVPN યુનિટ શું ગણે છે

નિષ્ફળ OpenVPN શરૂઆત ઘણી વાર સંસાધનની ફરિયાદ અને મર્યાદા વધારવાના સદ્ભાવપૂર્ણ સૂચન સાથે આવે છે, અને એ સૂચન ફક્ત અડધા જેટલા કિસ્સાઓમાં કામ કરે છે. એ નિષ્ફળતાઓ પાછળ બે અસંબંધિત કાઉન્ટર છે. એક કર્નલની મર્યાદા છે—વાસ્તવિક વપરાશકર્તા IDની માલિકીની ટાસ્કની સંખ્યા પર, અને પ્રક્રિયા ચલાવતી વખતે એ વારસાઈમાં મળે છે. બીજું cgroup બજેટ છે, જે સેવા મેનેજર એક યુનિટ અને એમાંથી ફોર્ક થતી દરેક વસ્તુ પર લાગુ કરે છે. જે યુનિટ ખરેખર ચાલે છે તેના માટે દરેકનું અસરકારક મૂલ્ય વાંચવું અનુમાન કરતાં ઓછું ખર્ચે છે.

બે કાઉન્ટર, બે પ્રશ્નો

LimitNPROC એ systemd નામ હેઠળ RLIMIT_NPROC છે, અને તેનું ગણતરી-એકમ વાસ્તવિક વપરાશકર્તા ID છે. એ વપરાશકર્તાની માલિકીની દરેક પ્રક્રિયા એ જ કુલમાં ગણાય છે, જેમાં બીજા યુનિટ, લોગિન સેશન કે શેડ્યુલર જોબે શરૂ કરેલું કામ પણ સામેલ છે. તેથી આ મર્યાદા સેવા યુનિટની અંદર સેટ કરવામાં આવે તો પણ સેવા-દીઠ મર્યાદા નથી, અને દરેક ક્લાયન્ટ માટે હેલ્પર ફોર્ક કરતી સેવા એ ખાતા હેઠળ ચાલતી બાકીની દરેક વસ્તુ સાથે સ્પર્ધા કરે છે. એ જ વપરાશકર્તા હેઠળનું વ્યસ્ત ક્રોન જોબ 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 જે એ જ તબક્કે હવે ટાસ્ક કે ફોર્ક ખતમ થવાની જાણ કરતું નથી. ફેરફાર સાથે પહેલાં-પછીની સંખ્યાઓ રાખો, જેથી આગળની તપાસ એ જ સલાહથી નહીં, માપણીથી શરૂ થાય. જો સંખ્યા હજુ મર્યાદા સુધી પહોંચે, તો ગણતરી ખોટી હતી, મર્યાદા આકસ્મિક રીતે નાની નહોતી, અને આગલા રીસ્ટાર્ટ પહેલાં એ ફરક જાણવો યોગ્ય છે.