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. ಬದಲಾವಣೆಯೊಂದಿಗೆ ಮೊದಲು-ನಂತರದ ಸಂಖ್ಯೆಗಳನ್ನು ಇರಿಸಿ, ಮುಂದಿನ ತನಿಖೆ ಅದೇ ಸಲಹೆಯಿಂದಲ್ಲ, ಅಳತೆಯಿಂದ ಆರಂಭವಾಗಲಿ. ಸಂಖ್ಯೆ ಇನ್ನೂ ಮೇಲ್ಮಿತಿ ತಲುಪಿದರೆ, ಲೆಕ್ಕಾಚಾರವೇ ತಪ್ಪಾಗಿತ್ತು, ಮಿತಿಯೇ ಆಕಸ್ಮಿಕವಾಗಿ ಚಿಕ್ಕದಾಗಿರಲಿಲ್ಲ, ಮತ್ತು ಮುಂದಿನ ಮರುಪ್ರಾರಂಭದ ಮೊದಲು ಈ ವ್ಯತ್ಯಾಸ ತಿಳಿಯುವುದು ಒಳ್ಳೆಯದು.