LimitNPROC සහ 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 එකකිනි. වෙනස සමඟ පෙර සහ පසු සංඛ්‍යා තබා ගන්න, ඊළඟ විමර්ශනය එම උපදෙසින් නොව මිනුමකින් ආරම්භ වන පරිදි. සංඛ්‍යාව තවමත් උඩු සීමාවට ළඟා වන්නේ නම්, ගණනයම වැරදි විය, සීමාව අහම්බෙන් ඉතා කුඩා නොවීය, සහ ඊළඟ නැවත ආරම්භයට පෙර එම වෙනස දැනගැනීම වටී.