کندی پروکسی در طول زمان: conntrack و محدودیتهای منابع را بررسی کنید
هنگامی که خطاها در طول زمان انباشته میشوند، فشار ردیابی اتصال را همراه با محدودیتهای منابع پروکسی و میزبان بررسی کنید.
پروکسی پس از راهاندازی مجدد پاسخ میدهد. چند ساعت بعد، اتصالهای جدید متوقف میشوند. راهاندازی مجدد یک بازه آرام دیگر میخرد. این الگو نشاندهنده وضعیت انباشته است، اما مشخص نمیکند کدام وضعیت مسئول است.
در مسیری لینوکسی که از ردیابی اتصال استفاده میکند، یک گزینه جدول conntrack است. این مقادیر موجود را روی ماشین و در فضای نام شبکهای که ترافیک را مدیریت میکند بررسی کنید:
/proc/sys/net/netfilter/nf_conntrack_count
/proc/sys/net/netfilter/nf_conntrack_maxاولی ورودیهای جریان تخصیصیافته را گزارش میکند؛ دومی آنها را محدود میکند. اینها شمار کاربران Squid یا درخواستهای HTTP نیستند. وضعیت جریان هسته میتواند از کار فعال برنامه بیشتر دوام بیاورد.
به دنبال رابطه باشید، نه فقط یک عدد بزرگ
اشغال را در طول زمان با آغاز خطاهای اتصالهای جدید و پیامهای مرتبط هسته مقایسه کنید. عدد بالا بدون شواهد خطای متناظر با جدولی که دقیقاً وقتی درخواستها شروع به پایان مهلت میکنند بارها به حد خود میرسد متفاوت است.
جدول ممکن است بیش از پروکسی را سرویس دهد. سرویسهای محلی دیگر، ترافیک ارسالشده یا مسیر شبکه شلوغ دیگر میتوانند سهم داشته باشند. اینکه راهاندازی مجدد پروکسی نشانه را تغییر دهد ثابت نمیکند که حافظه نهان اشیای Squid علت بوده است.
توضیحات رقیب را در نظر داشته باشید: توصیفگرهای فایل، صفهای کمککننده احراز هویت، تأخیرهای DNS، فشار حافظه و پر بودن فایلسیستم هم میتوانند در طول زمان بدتر شوند. ثبت کنید کدام منبع رشد میکند و کدام عملیات اول از کار میافتد. زنده ماندن اتصالهای دیرینه در حالی که اتصالهای جدید شکست میخورند شواهد مفیدی است، نه تشخیصی بهتنهایی.
افزایش یک محدودیت هزینه حافظه دارد. پیش از تغییر آن، بار کاری، فضای نام و ظرفیت موجود را مشخص کنید. کوتاه کردن بیرویه مهلتها میتواند نشستهای بیکار مفید را از بین ببرد؛ پاک کردن تمام وضعیت اتصال میتواند ترافیک بیربط را مختل کند.
نتیجه مفید توضیحی برای انباشت و تغییری در ظرفیت یا چرخه عمر است که با آن جور دربیاید. ایمن بودن برای افزایش ویژگیای نیست که هر سرور پروکسی آن را داشته باشد.