تباطؤ الوكيل مع الوقت: افحص conntrack وحدود الموارد

يستجيب الوكيل بعد إعادة التشغيل. وبعد بضع ساعات تتعطّل الاتصالات الجديدة. وإعادة التشغيل تشتري فترة هدوء أخرى. يشير هذا النمط إلى حالة متراكمة، لكنه لا يحدد أي حالة هي المسؤولة.

على مسار Linux يستخدم تتبّع الاتصالات، أحد المرشحين هو جدول conntrack. افحص هذه القيم الموجودة على الجهاز وفي فضاء أسماء الشبكة الذي يعالج حركة المرور:

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

الأول يبلّغ عن إدخالات التدفّق المخصّصة؛ والثاني يحدّ منها. وهي ليست أعدادًا لمستخدمي Squid أو لطلبات HTTP. يمكن لحالة التدفّق في النواة أن تعيش أطول من عمل التطبيق النشط.

ابحث عن علاقة، لا عن رقم كبير فقط

قارن الإشغال بمرور الوقت مع بداية أعطال الاتصالات الجديدة ورسائل النواة ذات الصلة. العدد المرتفع دون دليل عطل مطابق يختلف عن جدول يبلغ حدّه مرارًا في اللحظة التي تبدأ فيها الطلبات في انتهاء المهلة.

قد يخدم الجدول أكثر من الوكيل. خدمات محلية أخرى أو حركة معاد توجيهها أو مسار شبكة آخر مزدحم يمكن أن تسهم. تغيّر العَرَض بعد إعادة تشغيل الوكيل لا يثبت أن ذاكرة كائنات Squid هي السبب.

أبقِ التفسيرات المنافسة في الاعتبار: واصفات الملفات وقوائم مساعدي المصادقة وتأخيرات DNS وضغط الذاكرة ونظام ملفات ممتلئ يمكن أن تسوء أيضًا بمرور الوقت. سجّل أي مورد ينمو وأي العمليات تتوقف عن العمل أولًا. بقاء الاتصالات طويلة العمر بينما تفشل الجديدة دليل مفيد، وليس تشخيصًا بحد ذاته.

رفع الحدّ له كلفة في الذاكرة. قبل تغييره، حدّد عبء العمل وفضاء الأسماء والسعة المتاحة. تقصير المهل دون تمييز قد يكسر جلسات خاملة مفيدة؛ وتفريغ كل حالة الاتصال قد يعطّل حركة غير ذات صلة.

النتيجة المفيدة هي تفسير للتراكم وتغيير في السعة أو دورة الحياة يناسبه. كون الرفع آمنًا ليس خاصية تشترك فيها كل خوادم الوكيل.