समयसँगै प्रोक्सी ढिलो हुने: conntrack र स्रोत सीमाहरू जाँच्नुहोस्
समयसँगै विफलताहरू थुप्रिँदै जाँदा प्रोक्सी र होस्टका स्रोत सीमाहरूसँगै जडान-ट्र्याकिङको दबाब अन्वेषण गर्नुहोस्।
पुनः सुरु गरेपछि प्रोक्सीले प्रतिक्रिया दिन्छ। केही घण्टापछि नयाँ जडानहरू अड्किन्छन्। फेरि सुरु गर्दा अर्को शान्त अवधि किनिन्छ। यो ढाँचाले थुप्रिँदै गएको अवस्था देखाउँछ, तर कुन अवस्था जिम्मेवार हो भनी पहिचान गर्दैन।
जडान ट्र्याकिङ प्रयोग गर्ने Linux मार्गमा एउटा सम्भावित कारण conntrack तालिका हो। मेसिनमा र ट्राफिक हेर्ने नेटवर्क नेमस्पेसमा यी विद्यमान मानहरू जाँच्नुहोस्:
/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_maxपहिलोले तोकिएका फ्लो प्रविष्टिहरू जनाउँछ; दोस्रोले तिनलाई सीमित गर्छ। यी Squid प्रयोगकर्ता वा HTTP अनुरोधका गणना होइनन्। कर्नेलको फ्लो अवस्था अनुप्रयोगको सक्रिय कामभन्दा लामो समय टिक्न सक्छ।
ठूलो सङ्ख्या मात्र नभई सम्बन्ध खोज्नुहोस्
समयसँगैको भराइलाई नयाँ जडानका विफलता सुरु हुने र सान्दर्भिक कर्नेल सन्देशसँग तुलना गर्नुहोस्। उपयुक्त विफलता प्रमाण नभएको उच्च गणना, अनुरोधहरू समय सकिन थाल्दा बारम्बार आफ्नो सीमा पुग्ने तालिकाभन्दा फरक हुन्छ।
तालिकाले प्रोक्सीभन्दा बढी सेवा गर्न सक्छ। अन्य स्थानीय सेवा, अगाडि पठाइएको ट्राफिक वा अर्को व्यस्त नेटवर्क मार्गले योगदान गर्न सक्छ। प्रोक्सी पुनः सुरु गर्दा लक्षण बदलिनुले Squid को वस्तु क्यास कारण थियो भनी प्रमाणित गर्दैन।
प्रतिस्पर्धी व्याख्याहरू आँखाअगाडि राख्नुहोस्: फाइल डिस्क्रिप्टरहरू, प्रमाणीकरण सहायकका लाइन, DNS ढिलाइ, मेमोरी दबाब र भरिएको फाइलसिस्टम पनि समयसँगै बिग्रन सक्छन्। कुन स्रोत बढिरहेको छ र कुन कार्यहरू पहिले काम गर्न छाड्छन् भनी लेख्नुहोस्। दीर्घजीवी जडानहरू टिकिरहँदा नयाँ विफल हुनु उपयोगी प्रमाण हो, आफैँमा निदान होइन।
सीमा बढाउनुको मेमोरी लागत हुन्छ। बदल्नुअघि कार्यभार, नेमस्पेस र उपलब्ध क्षमता निर्धारण गर्नुहोस्। बिना सोचाइ समयसीमा छोटो बनाउँदा उपयोगी निष्क्रिय सत्र भाँचिन सक्छ; सबै जडान अवस्था मेटाउँदा असम्बन्धित ट्राफिक अवरुद्ध हुन सक्छ।
उपयोगी नतिजा थुप्रिने प्रक्रियाको व्याख्या र त्यससँग मिल्ने क्षमता वा जीवनचक्र परिवर्तन हो। बढाउनु सुरक्षित हुनु हरेक प्रोक्सी सर्भरमा हुने गुण होइन।