Squid ನ ನಿಜವಾದ ಫೈಲ್-ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಮಿತಿಯನ್ನು ಕಂಡುಹಿಡಿಯುವುದು
PAM ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಬದಲಿಸುವ ಅಥವಾ ಸಾಮರ್ಥ್ಯದ ಪಾಕವಿಧಾನದಿಂದ ಸ್ಥಿರ nofile ಮೌಲ್ಯವನ್ನು ನಕಲಿಸುವ ಮೊದಲು ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರಾಕ್ಸಿಯ ಪ್ರಕ್ರಿಯೆ ಮಿತಿಗಳನ್ನು ಓದಿ.
ಲಾಗಿನ್ ಶೆಲ್‌ನ ulimit -n ಅನ್ನು ನಂಬುವ ಮೊದಲು ಚಾಲನೆಯಲ್ಲಿರುವ ಡೀಮನ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ. squid.service ಬಳಸುವ ಸ್ಥಾಪನೆಗಾಗಿ ಇದರಿಂದ ಪ್ರಾರಂಭಿಸಿ:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceನಿಜವಾದ ಪ್ರಕ್ರಿಯೆ ID ಬಳಸಿ /proc/PID/limits ಓದಿ. ಬಹು-ಪ್ರಕ್ರಿಯೆ ನಿಯೋಜನೆಯಲ್ಲಿ ಸಂಬಂಧಿತ ವರ್ಕರ್ ಅನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಉಳಿಸಿದ ಮೌಲ್ಯವು ಈ ಪ್ರಕ್ರಿಯೆ ಅದನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆದಿದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿಯಲ್ಲ.
| ನಿಯಂತ್ರಣ | ವ್ಯಾಪ್ತಿ |
|---|---|
ಶೆಲ್ ulimit ಮತ್ತು PAM limits.conf | ಶೆಲ್‌ನ ವಂಶಸ್ಥರು ಅಥವಾ PAM ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ನಿಜವಾಗಿ ಬಳಸುವ ಸೆಷನ್‌ಗಳು |
systemd LimitNOFILE= | ಆ ಸೇವೆಯ ಸಂಪನ್ಮೂಲ ನೀತಿಯ ಅಡಿಯಲ್ಲಿ ಪ್ರಾರಂಭವಾದ ಪ್ರಕ್ರಿಯೆಗಳು |
Squid max_filedescriptors, ಬೆಂಬಲವಿರುವಲ್ಲಿ | ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ಮಿತಿಗಳೊಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ ಮಿತಿ |
ನಿರ್ವಾಹಕರು ಫೈಲ್ ಬದಲಿಸಿದ್ದಾರೆ ಎಂಬ ಕಾರಣಕ್ಕೆ ಮಾತ್ರ ಸಿಸ್ಟಂ ಸೇವೆ PAM ಬದಲಾವಣೆಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದಿಲ್ಲ. systemd ಮಿತಿಯನ್ನು ಬದಲಿಸುವುದು ಸೂಕ್ತವಾದಾಗ ಸೇವಾ-ನಿರ್ದಿಷ್ಟ drop-in ಬಳಸಿ. Squid ದಾಖಲಿಸುವಂತೆ max_filedescriptors ಬದಲಾಗಲು ಮರುಪ್ರಾರಂಭ ಬೇಕು; ಹೊಂದಿಸದೆ ಬಿಟ್ಟರೆ OS ನ ಮೃದು ಮಿತಿಯನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯುತ್ತದೆ.
ಮಿತಿಯನ್ನು ಬಳಕೆದಾರರಿಗಲ್ಲ, ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳಿಗೆ ಅಳೆಯಿರಿ. ಗ್ರಾಹಕರು ಹಲವು ಸಾಕೆಟ್‌ಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಬಹುದು, ಮತ್ತು ಹೊರಹೋಗುವ ಸಂಪರ್ಕಗಳು, ಲಾಗ್‌ಗಳು ಹಾಗೂ ಸಹಾಯಕ ಪೈಪ್‌ಗಳೂ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ. ಮಿತಿ ಹೆಚ್ಚಿಸಿದರೆ ಪ್ರತಿ ಸಂಭಾವ್ಯ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗೂ ತಕ್ಷಣ ಸ್ಥಿರ RAM ಕಾಯ್ದಿರಿಸದೆ ಹೆಚ್ಚು ಬಳಕೆ ಸಾಧ್ಯ. ಹಳೆಯ ಪ್ರತಿ-ಸಾಕೆಟ್ ಮೆಮೊರಿ ಅಂದಾಜು ಆಗಲಿ 65,535 ಆಗಲಿ ಸಾರ್ವತ್ರಿಕ ಸಾಮರ್ಥ್ಯದ ಅಗತ್ಯವಲ್ಲ ಅಥವಾ Linux ನ ಮೇಲ್ಮಿತಿಯೂ ಅಲ್ಲ.
ಸೇವೆ ಬದಲಾವಣೆಯ ನಂತರ ಹೊಸ ಪ್ರಕ್ರಿಯೆಯ ಮಿತಿಗಳನ್ನು ಉದ್ದೇಶಿತ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಹೋಲಿಸಿ. ಅವುಗಳಿಗಿಂತ ಬಹಳ ಕೆಳಗೆ ವೈಫಲ್ಯಗಳು ಸಂಭವಿಸಿದರೆ, ನಿಜವಾಗಿ ಖಾಲಿಯಾಗುತ್ತಿರುವ ಸಂಪನ್ಮೂಲವನ್ನು ತನಿಖೆ ಮಾಡಿ.