સમય જતાં પ્રોક્સી ધીમી પડવી: conntrack અને સંસાધન મર્યાદા તપાસો

પુનઃપ્રારંભ પછી પ્રોક્સી પ્રતિસાદ આપે છે. થોડા કલાકો પછી નવા કનેક્શન અટકી જાય છે. ફરી પુનઃપ્રારંભ કરવાથી બીજો શાંત સમયગાળો મળે છે. આ પેટર્ન એકઠી થતી સ્થિતિ સૂચવે છે, પણ કઈ સ્થિતિ જવાબદાર છે તે ઓળખતું નથી.

કનેક્શન ટ્રેકિંગ વાપરતા Linux માર્ગ પર એક સંભવિત કારણ conntrack કોષ્ટક છે. મશીન પર અને ટ્રાફિક સંભાળતા નેટવર્ક નેમસ્પેસમાં આ હાલનાં મૂલ્યો તપાસો:

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

પ્રથમ ફાળવેલ ફ્લો એન્ટ્રી જણાવે છે; બીજું તેમને મર્યાદિત કરે છે. આ Squid વપરાશકર્તાઓ કે HTTP વિનંતીઓની ગણતરી નથી. કર્નલની ફ્લો સ્થિતિ એપ્લિકેશનના સક્રિય કામ કરતાં વધુ ટકી શકે છે.

ફક્ત મોટી સંખ્યા નહીં, સંબંધ શોધો

સમય જતાં ભરાવાની સ્થિતિને નવા કનેક્શનની નિષ્ફળતાઓની શરૂઆત અને સંબંધિત કર્નલ સંદેશાઓ સાથે સરખાવો. યોગ્ય નિષ્ફળતાના પુરાવા વિનાની ઊંચી ગણતરી એ કોષ્ટક કરતાં અલગ છે જે વિનંતીઓ સમય સમાપ્ત થવા લાગે ત્યારે વારંવાર તેની મર્યાદા સુધી પહોંચે છે.

કોષ્ટક પ્રોક્સીથી વધુ સેવા આપી શકે છે. અન્ય સ્થાનિક સેવાઓ, આગળ મોકલાયેલ ટ્રાફિક કે બીજો વ્યસ્ત નેટવર્ક માર્ગ ફાળો આપી શકે છે. પ્રોક્સી પુનઃપ્રારંભ કરવાથી લક્ષણ બદલાય તે એ સાબિત કરતું નથી કે Squidની ઑબ્જેક્ટ કૅશ કારણ હતી.

સ્પર્ધાત્મક સમજૂતીઓ ધ્યાનમાં રાખો: ફાઇલ ડિસ્ક્રિપ્ટર, પ્રમાણીકરણ સહાયકોની કતારો, DNS વિલંબ, મેમરી દબાણ અને ભરેલી ફાઇલસિસ્ટમ પણ સમય જતાં બગડી શકે છે. કયો સંસાધન વધે છે અને કઈ કામગીરી પહેલા બંધ પડે છે તે નોંધો. લાંબા આયુષ્યના કનેક્શન ટકી રહે જ્યારે નવા નિષ્ફળ જાય એ ઉપયોગી પુરાવો છે, પોતે નિદાન નથી.

મર્યાદા વધારવાની મેમરી કિંમત છે. બદલતા પહેલા કામનો ભાર, નેમસ્પેસ અને ઉપલબ્ધ ક્ષમતા નક્કી કરો. અવિચારે સમયમર્યાદા ટૂંકી કરવાથી ઉપયોગી નિષ્ક્રિય સત્રો તૂટી શકે છે; બધી કનેક્શન સ્થિતિ સાફ કરવાથી અસંબંધિત ટ્રાફિક ખલેલ પામી શકે છે.

ઉપયોગી પરિણામ એ સંચયની સમજૂતી અને તેને અનુરૂપ ક્ષમતા કે જીવનચક્રનો ફેરફાર છે. વધારવું સુરક્ષિત છે એ દરેક પ્રોક્સી સર્વરમાં હોય એવો ગુણ નથી.