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 को माथिल्लो सीमा हो।
सेवा परिवर्तनपछि नयाँ प्रक्रियाको सीमा इच्छित मानसँग तुलना गर्नुहोस्। तिनीभन्दा धेरै तल विफलता देखिएमा वास्तवमै सकिँदै गरेको स्रोतको अनुसन्धान गर्नुहोस्।