समय के साथ प्रॉक्सी का धीमा होना: conntrack और संसाधन सीमाएँ जाँचें

पुनः आरंभ के बाद प्रॉक्सी प्रतिक्रिया देता है। कुछ घंटों बाद नए कनेक्शन अटक जाते हैं। फिर से आरंभ करना एक और शांत अंतराल खरीदता है। यह पैटर्न जमा होती स्थिति का संकेत देता है, पर यह नहीं बताता कि कौन-सी स्थिति ज़िम्मेदार है।

कनेक्शन ट्रैकिंग का उपयोग करने वाले Linux पथ पर एक संभावित कारण conntrack तालिका है। मशीन पर और ट्रैफ़िक संभालने वाले नेटवर्क नेमस्पेस में ये मौजूदा मान जाँचें:

/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_max

पहला आवंटित फ़्लो प्रविष्टियाँ बताता है; दूसरा उन्हें सीमित करता है। ये Squid उपयोगकर्ताओं या HTTP अनुरोधों की गिनती नहीं हैं। कर्नेल की फ़्लो स्थिति एप्लिकेशन के सक्रिय काम से अधिक समय तक जीवित रह सकती है।

केवल बड़ी संख्या नहीं, संबंध खोजें

समय के साथ भरेपन की तुलना नए कनेक्शन की विफलताओं के शुरू होने और संबंधित कर्नेल संदेशों से करें। उपयुक्त विफलता प्रमाण के बिना ऊँची गिनती उस तालिका से अलग है जो अनुरोधों का समय समाप्त होना शुरू होते ही बार-बार अपनी सीमा तक पहुँचती है।

तालिका प्रॉक्सी से अधिक की सेवा कर सकती है। अन्य स्थानीय सेवाएँ, अग्रेषित ट्रैफ़िक या कोई अन्य व्यस्त नेटवर्क पथ योगदान दे सकते हैं। प्रॉक्सी का पुनः आरंभ लक्षण बदल देता है, इससे यह सिद्ध नहीं होता कि Squid का ऑब्जेक्ट कैश कारण था।

प्रतिस्पर्धी व्याख्याओं पर नज़र रखें: फ़ाइल डिस्क्रिप्टर, प्रमाणीकरण सहायकों की कतारें, DNS देरी, मेमोरी दबाव और भरी फ़ाइलसिस्टम भी समय के साथ बिगड़ सकते हैं। लिखें कि कौन-सा संसाधन बढ़ता है और कौन-से संचालन पहले काम करना बंद करते हैं। दीर्घकालिक कनेक्शन का जीवित रहना जबकि नए विफल होना उपयोगी प्रमाण है, अपने आप में निदान नहीं।

सीमा बढ़ाने की मेमोरी लागत होती है। बदलने से पहले कार्यभार, नेमस्पेस और उपलब्ध क्षमता निर्धारित करें। बिना सोचे समय-सीमाएँ छोटी करना उपयोगी निष्क्रिय सत्र तोड़ सकता है; सारी कनेक्शन स्थिति साफ़ करना असंबंधित ट्रैफ़िक को बाधित कर सकता है।

उपयोगी परिणाम जमावट की व्याख्या और उससे मेल खाता क्षमता या जीवनचक्र परिवर्तन है। बढ़ाना सुरक्षित है — यह हर प्रॉक्सी सर्वर में मौजूद गुण नहीं है।