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 वापरा. max_filedescriptors बदलण्यासाठी पुन्हा सुरू करणे आवश्यक आहे असे Squid नोंदवते; सेट न करता सोडल्यास OS ची मऊ मर्यादा वारशाने मिळते.
मर्यादा वापरकर्त्यांसाठी नाही, डिस्क्रिप्टरसाठी मोजा. ग्राहक अनेक सॉकेट ठेवू शकतात, आणि बाहेर जाणारे कनेक्शन, लॉग व सहाय्यक पाइपही डिस्क्रिप्टर वापरतात. मर्यादा वाढवल्यास प्रत्येक संभाव्य डिस्क्रिप्टरसाठी त्वरित ठराविक RAM राखून न ठेवता अधिक वापर शक्य होतो. जुना प्रति-सॉकेट मेमरी अंदाज किंवा 65,535 यापैकी कोणतेही सार्वत्रिक क्षमता-आवश्यकता किंवा Linux ची वरची मर्यादा नाही.
सेवा बदलल्यानंतर नव्या प्रक्रियेच्या मर्यादा इच्छित मूल्यांशी तुलना करा. त्यांच्याखाली खूप खाली अपयश येत असल्यास प्रत्यक्षात संपत असलेल्या संसाधनाची चौकशी करा.