وقت کے ساتھ پراکسی کا سست ہونا: conntrack اور وسائل کی حدیں جانچیں

دوبارہ شروع ہونے کے بعد پراکسی جواب دیتی ہے۔ چند گھنٹوں بعد نئے کنکشن اٹک جاتے ہیں۔ دوبارہ شروع کرنا ایک اور پرسکون وقفہ خرید لیتا ہے۔ یہ نمونہ جمع ہوتی حالت کی نشاندہی کرتا ہے، مگر یہ نہیں بتاتا کہ کون سی حالت ذمہ دار ہے۔

کنکشن ٹریکنگ استعمال کرنے والے Linux راستے پر ایک ممکنہ وجہ conntrack جدول ہے۔ مشین پر اور ٹریفک سنبھالنے والے نیٹ ورک نیم اسپیس میں یہ موجودہ اقدار جانچیں:

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

پہلا مختص شدہ فلو اندراجات بتاتا ہے؛ دوسرا انہیں محدود کرتا ہے۔ یہ Squid صارفین یا HTTP درخواستوں کی گنتی نہیں ہیں۔ کرنل کی فلو حالت ایپلیکیشن کے فعال کام سے زیادہ عرصہ زندہ رہ سکتی ہے۔

صرف بڑی تعداد نہیں، تعلق تلاش کریں

وقت کے ساتھ بھراؤ کا موازنہ نئے کنکشن کی ناکامیوں کے آغاز اور متعلقہ کرنل پیغامات سے کریں۔ مناسب ناکامی کے ثبوت کے بغیر زیادہ گنتی اس جدول سے مختلف ہے جو درخواستوں کی مدت ختم ہونے لگنے پر بار بار اپنی حد تک پہنچتا ہے۔

جدول پراکسی سے زیادہ کی خدمت کر سکتا ہے۔ دیگر مقامی خدمات، آگے بھیجا گیا ٹریفک یا کوئی اور مصروف نیٹ ورک راستہ حصہ ڈال سکتا ہے۔ پراکسی کو دوبارہ شروع کرنے سے علامت بدلنا یہ ثابت نہیں کرتا کہ Squid کا آبجیکٹ کیش سبب تھا۔

مدمقابل وضاحتیں نظر میں رکھیں: فائل ڈسکرپٹرز، تصدیق کے معاونین کی قطاریں، DNS تاخیر، میموری کا دباؤ اور بھرا ہوا فائل سسٹم بھی وقت کے ساتھ بگڑ سکتے ہیں۔ لکھیں کہ کون سا وسیلہ بڑھ رہا ہے اور کون سی کارروائیاں پہلے کام کرنا بند کرتی ہیں۔ طویل العمر کنکشن کا بچا رہنا جبکہ نئے ناکام ہوں مفید ثبوت ہے، بذات خود تشخیص نہیں۔

حد بڑھانے کی میموری لاگت ہوتی ہے۔ بدلنے سے پہلے کام کا بوجھ، نیم اسپیس اور دستیاب صلاحیت متعین کریں۔ بلا سوچے سمجھے ٹائم آؤٹ کم کرنا مفید غیر فعال سیشن توڑ سکتا ہے؛ تمام کنکشن حالت صاف کرنا غیر متعلقہ ٹریفک میں خلل ڈال سکتا ہے۔

مفید نتیجہ جمع ہونے کی وضاحت اور اس سے مطابقت رکھنے والی صلاحیت یا زندگی کے دورانیے کی تبدیلی ہے۔ بڑھانا محفوظ ہونا ہر پراکسی سرور میں موجود خصوصیت نہیں ہے۔