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 की ऊपरी सीमा है।

सेवा बदलाव के बाद नई प्रक्रिया की सीमाओं की तुलना इच्छित मानों से करें। यदि विफलताएँ उनसे बहुत नीचे होती हैं, तो वास्तव में समाप्त हो रहे संसाधन की जाँच करें।

संबंधित लेख