یافتن حد واقعی توصیف‌گر فایل در Squid
پیش از تغییر تنظیمات PAM یا کپی کردن مقدار ثابت nofile از یک دستور ظرفیت، محدودیت‌های فرایند پروکسی در حال اجرا را بخوانید.
پیش از اعتماد به ulimit -n پوسته ورود، دیمن در حال اجرا را بررسی کنید. برای نصب‌ای که از squid.service استفاده می‌کند، با این شروع کنید:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service/proc/PID/limits را با شناسه واقعی فرایند بخوانید. در استقرار چندفرایندی، کارگر مربوطه را هم بررسی کنید. مقداری که در پیکربندی ذخیره شده اثبات وراثت آن توسط این فرایند نیست.
| کنترل | دامنه |
|---|---|
پوسته ulimit و PAM limits.conf | فرزندان پوسته یا نشست‌هایی که واقعاً از تنظیم PAM استفاده می‌کنند |
systemd LimitNOFILE= | فرایندهایی که زیر سیاست منابع آن سرویس آغاز شده‌اند |
Squid max_filedescriptors، در صورت پشتیبانی | حد برنامه در چارچوب محدودیت‌های سیستم‌عامل |
یک سرویس سیستم فقط به این دلیل که مدیر فایل را تغییر داده، ویرایش‌های PAM را نمی‌پذیرد. وقتی تغییر حد systemd مناسب است، از drop-in مخصوص همان سرویس استفاده کنید. Squid مستند می‌کند که max_filedescriptors برای تغییر نیاز به راه‌اندازی مجدد دارد؛ اگر تنظیم نشده بماند، حد نرم سیستم‌عامل به ارث می‌رسد.
حد را بر اساس توصیف‌گرها اندازه بگیرید، نه کاربران. کاربران می‌توانند چندین سوکت نگه دارند، و اتصال‌های خروجی، گزارش‌ها و لوله‌های کمکی هم توصیف‌گر مصرف می‌کنند. بالا بردن حد مصرف بیشتر را ممکن می‌کند بی‌آنکه همان لحظه مقدار ثابتی RAM برای هر توصیف‌گر ممکن رزرو شود. نه برآورد قدیمی حافظه به‌ازای هر سوکت و نه 65,535 هیچ‌یک نیاز جهانی ظرفیت یا سقف لینوکس نیست.
پس از تغییر سرویس، محدودیت‌های فرایند جدید را با مقادیر موردنظر مقایسه کنید. اگر خطاها بسیار پایین‌تر از آن‌ها رخ دهند، منبعی را که واقعاً تمام می‌شود بررسی کنید.