Entry Processes یا EP یکی از شاخص‌های محدودیت منابع در بسیاری از هاست‌های مبتنی بر CloudLinux است. این عدد، شمار بازدیدکنندگان سایت یا تعداد همهٔ پردازش‌های حساب نیست. برای تفسیر درست باید نوع وب‌سرور، روش اجرای PHP و گزارش همان سرویس را در نظر گرفت.
Entry Processes چه چیزی را می‌شمارد؟
در پیاده‌سازی Apache، ورود درخواست به محیط LVE و خروج آن در این شمارنده اثر دارد. پردازش‌های فرزند الزاماً هرکدام یک EP جدا نیستند. رفتار LiteSpeed متفاوت است و نباید تعریف Apache را بدون تغییر به آن تعمیم داد. محدودیت NPROC نیز شاخص جداگانه‌ای برای تعداد پردازش‌هاست.
چرا EP به سقف می‌رسد؟
وقتی درخواست‌ها دیر تمام شوند، درخواست‌های جدید هم‌زمان با آن‌ها باقی می‌مانند. کندی دیتابیس، انتظار برای API خارجی، اجرای سنگین افزونه، افزایش ترافیک یا درخواست‌های مخرب می‌توانند دخیل باشند. یک بازدیدکننده ممکن است چند درخواست ایجاد کند و همهٔ فایل‌های کش‌شده نیز رفتار یکسانی ندارند.
رابطه با خطای 508
در حالت مستند Apache و CloudLinux، رسیدن به سقف EP می‌تواند خطای 508 ایجاد کند. هر خطای 500 یا 503 را به EP نسبت ندهید؛ حافظه، NPROC و خطاهای برنامه هم باید بررسی شوند. کد وضعیت را همراه با زمان و متن لاگ تفسیر کنید، نه فقط رنگ نمودار.
مسیر عیب‌یابی
- زمان دقیق خطا و URL درگیر را ثبت کنید.
- در گزارش منابع، EP و تعداد رخدادهای رسیدن به سقف را در همان بازه ببینید.
- درخواست‌های کند و پرتکرار را از لاگ دسترسی پیدا کنید.
- هم‌زمانی کرون، بک‌آپ، ایمپورت و درخواست‌های خارجی را بررسی کنید.
- عامل مشخص را اصلاح کنید و اثر آن را روی زمان پاسخ ببینید.
راه‌حل‌های مؤثر و اشتباه‌های رایج
کش صفحات عمومی و کاهش زمان پردازش می‌تواند هم‌زمانی را کم کند. درخواست‌های مشکوک را بر اساس شواهد و با روش مناسب میزبان محدود کنید. حذف یا ویرایش متن error_log خطای برنامه را درمان نمی‌کند؛ لاگ محل مشاهدهٔ نشانه‌هاست. کشتن همهٔ پردازش‌ها یا انتظار نامحدود برای «خالی‌شدن RAM» نیز راه‌حل عمومی EP نیست.
اگر بار مشروع پس از بهینه‌سازی همچنان از سقف می‌گذرد، تغییر سهمیه یا سرویس را با میزبان بررسی کنید. مستند محدودیت‌های CloudLinux مرجع تفاوت EP، NPROC و رفتار وب‌سرورهاست.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
