काळानुसार प्रॉक्सीचा संथपणा: conntrack आणि संसाधन मर्यादा तपासा

पुन्हा सुरू केल्यावर प्रॉक्सी प्रतिसाद देतो. काही तासांनंतर नवीन कनेक्शन अडकतात. पुन्हा सुरू केल्याने अजून एक शांत कालावधी मिळतो. हा नमुना साचणारी स्थिती दर्शवतो, पण कोणती स्थिती जबाबदार आहे हे सांगत नाही.

कनेक्शन ट्रॅकिंग वापरणाऱ्या Linux मार्गावर एक संभाव्य कारण conntrack तक्ता आहे. मशीनवर आणि रहदारी हाताळणाऱ्या नेटवर्क नेमस्पेसमध्ये ही विद्यमान मूल्ये तपासा:

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

पहिला वाटप केलेल्या फ्लो नोंदी सांगतो; दुसरा त्यांना मर्यादित करतो. हे Squid वापरकर्ते किंवा HTTP विनंत्या यांची मोजणी नाही. कर्नेलची फ्लो स्थिती ॲप्लिकेशनच्या सक्रिय कामापेक्षा जास्त काळ टिकू शकते.

फक्त मोठी संख्या नाही, संबंध शोधा

काळानुसार भरण्याची तुलना नवीन कनेक्शनच्या अपयशाच्या सुरुवातीशी आणि संबंधित कर्नेल संदेशांशी करा. योग्य अपयशाचा पुरावा नसलेली उच्च मोजणी, विनंत्या वेळेच्या मर्यादा ओलांडू लागताच वारंवार आपली मर्यादा गाठणाऱ्या तक्त्यापेक्षा वेगळी आहे.

तक्ता प्रॉक्सीपेक्षा अधिक सेवा देऊ शकतो. इतर स्थानिक सेवा, पुढे पाठवलेली रहदारी किंवा दुसरा व्यस्त नेटवर्क मार्ग योगदान देऊ शकतो. प्रॉक्सी पुन्हा सुरू केल्याने लक्षण बदलते याचा अर्थ Squidचा ऑब्जेक्ट कॅश कारण होता असे सिद्ध होत नाही.

स्पर्धात्मक स्पष्टीकरणे लक्षात ठेवा: फाइल डिस्क्रिप्टर, प्रमाणीकरण सहाय्यकांच्या रांगा, DNS विलंब, मेमरीचा दबाव आणि भरलेली फाइलसिस्टम ही देखील काळानुसार बिघडू शकतात. कोणते संसाधन वाढते आणि कोणती क्रिया प्रथम काम करणे थांबवते ते नोंदवा. दीर्घायुषी कनेक्शन टिकून राहणे आणि नवीन अपयशी होणे हा उपयुक्त पुरावा आहे, स्वतःहून निदान नाही.

मर्यादा वाढवण्यास मेमरीचा खर्च येतो. बदलण्यापूर्वी कामाचा भार, नेमस्पेस आणि उपलब्ध क्षमता निश्चित करा. वेळेच्या मर्यादा अविचाराने कमी केल्यास उपयुक्त निष्क्रिय सत्रे तुटू शकतात; सर्व कनेक्शन स्थिती पुसल्यास असंबंधित रहदारी बाधित होऊ शकते.

उपयुक्त परिणाम म्हणजे साचण्याचे स्पष्टीकरण आणि त्याला अनुरूप क्षमता किंवा जीवनचक्रातील बदल. वाढवणे सुरक्षित आहे हा गुण प्रत्येक प्रॉक्सी सर्व्हरमध्ये नसतो.