رفع خطای 508 Resource Limit Reached در CloudLinux؛ عیب‌یابی EP، CPU و PMEM

خطای 508 Resource Limit Reached روی هاست‌های مبتنی بر CloudLinux معمولاً زمانی دیده می‌شود که تعداد درخواست‌های هم‌زمان واردشونده به محیط LVE یک حساب از سقف Entry Processes یا EP عبور کند. این پیام به‌خودی‌خود به معنی پر شدن RAM یا CPU نیست. برای تشخیص، زمان بروز خطا را با بخش Resource Usage در cPanel و به‌ویژه شمارنده EP Faults تطبیق دهید؛ سپس علت طولانی شدن یا زیاد شدن درخواست‌ها را پیدا کنید.

در مستندات رسمی CloudLinux درباره محدودیت‌های LVE آمده است که رسیدن به سقف Entry Processes می‌تواند پاسخ 508 ایجاد کند. در مقابل، رسیدن به محدودیت CPU اغلب باعث کند شدن پاسخ می‌شود و محدودیت حافظه ممکن است با خطاهای 500 یا 503 همراه باشد. بنابراین پیش از تغییر پلن یا افزایش منابع، نوع Fault را مشخص کنید.

پیش‌نیازها و تشخیص اینکه خطا واقعاً از CloudLinux است

این راهنما برای حساب‌های میزبانی دارای CloudLinux و برای مدیران سرور WHM/cPanel کاربرد دارد. کاربر هاست معمولاً به cPanel دسترسی دارد؛ دستورهای lveinfo و lvetop مخصوص مدیر سرور با دسترسی SSH مناسب هستند. ابتدا متن دقیق خطا، ساعت وقوع و دامنه آسیب‌دیده را ثبت کنید. هر پاسخ HTTP با کد 508 لزوماً از CloudLinux نیست؛ عبارت «Resource Limit Reached» و آمار LVE قرینه مهمی هستند.

curl -sS -o /dev/null -w 'HTTP %{http_code}n' https://example.com/

دامنه نمونه را با دامنه خودتان جایگزین کنید. این آزمایش را چند بار در زمان عادی و زمان خطا تکرار کنید؛ پاسخ 200 در یک لحظه، وجود خطای مقطعی 508 را رد نمی‌کند. اگر CDN یا پراکسی جلوی سایت قرار دارد، کد و زمان پاسخ مبدأ را هم بررسی کنید.

مرحله اول: پیدا کردن EP Fault در cPanel Resource Usage

1. وارد cPanel شوید و در بخش Metrics یا جستجوی پنل، گزینه Resource Usage را باز کنید؛ نام و محل دقیق آن به نسخه و تنظیمات میزبان بستگی دارد.
2. در Current Usage، بازه زمانی نزدیک به وقوع خطا را انتخاب و ستون‌های Usage، Limit و Fault را بررسی کنید.
3. به EP و تعداد خطاهای EPf توجه کنید. افزایش Fault در همان ساعت وقوع 508 نشانه‌ای قوی از رسیدن به سقف ورود درخواست‌هاست.
4. اگر Snapshot در پنل فعال است، فرآیندها و درخواست‌های همان بازه را بررسی کنید. ممکن است این بخش در همه سرویس‌ها فعال نباشد.

در راهنمای CloudLinux Manager و Resource Usage، نمودارها و Snapshotها شرح داده شده‌اند. EP شمار بازدیدکنندگان آنلاین نیست؛ درخواست‌های هم‌زمانی را نشان می‌دهد که به محیط اجرای حساب وارد شده‌اند. حتی با بازدید کم، چند درخواست PHP کند می‌توانند EP را برای مدتی اشغال کنند.

تفاوت EP، CPU، PMEM و NPROC در گزارش

شاخص	معنا	برداشت درست
EP / EPf	ورود درخواست‌های هم‌زمان به LVE / تعداد دفعات برخورد با سقف	برای 508 در CloudLinux اولویت اول بررسی است.
CPU / CPUf	مصرف پردازنده و برخورد با سقف پردازشی	اغلب با کندی همراه است؛ به‌تنهایی علت قطعی 508 نیست.
PMEM / PMEMf	حافظه فیزیکی و رخدادهای عبور از محدودیت	ممکن است فرآیندها خاتمه یابند و 500/503 رخ دهد.
NPROC / NprocF	تعداد فرآیندها و برخورد با سقف آن	از EP متفاوت است؛ محدودیت را جداگانه بررسی کنید.

مرحله دوم: عیب‌یابی از سمت مدیر سرور با lveinfo و lvetop

اگر مدیر سرور هستید، با دسترسی مجاز SSH گزارش تاریخی و مصرف فعلی را مشاهده کنید. این دستورها برای مشاهده هستند و تنظیمات کاربران را تغییر نمی‌دهند:

sudo lveinfo --period 1d --by-fault ep
sudo lveinfo --period 1d -u CPANEL_USER
sudo lvetop

CPANEL_USER را با نام واقعی حساب جایگزین کنید. گزینه --by-fault ep حساب‌هایی را که خطای EP داشته‌اند فیلتر می‌کند؛ lveinfo -u آمار همان حساب را در بازه انتخابی نشان می‌دهد و lvetop نمای لحظه‌ای مصرف را ارائه می‌کند. قالب خروجی و امکانات به نسخه LVE Stats بستگی دارد؛ برای پارامترهای دقیق از مرجع رسمی ابزارهای خط فرمان CloudLinux استفاده کنید.

اگر دستورها روی هاست اشتراکی در دسترس نیستند، به‌جای تلاش برای گرفتن دسترسی root، گزارش Resource Usage و زمان خطا را برای پشتیبانی میزبان ارسال کنید. اسکرین‌شات‌ها و Snapshotها ممکن است نشانی‌های خصوصی یا جزئیات درخواست کاربران را نشان دهند؛ آن‌ها را عمومی منتشر نکنید.

مرحله سوم: پیدا کردن علت افزایش درخواست‌های هم‌زمان

درخواست‌های کند PHP، افزونه‌ها و پایگاه داده

درخواست PHP که مدت زیادی منتظر کوئری پایگاه داده، API خارجی یا فایل قفل‌شده می‌ماند، ظرفیت هم‌زمانی را اشغال می‌کند. برای پیدا کردن مسیر کند، لاگ‌های وب‌سرور و PHP را با ساعت Fault تطبیق دهید. در سرویس‌هایی که دسترسی لازم وجود دارد، عیب‌یابی کندی PHP با PHP-FPM Slow Log کمک می‌کند تابع یا اسکریپت کند را شناسایی کنید؛ فعال بودن و مسیر این لاگ در همه پلن‌های اشتراکی یکسان نیست.

درخواست‌های پرتکرار وردپرس و admin-ajax.php

در وردپرس، افزونه‌ها، Heartbeat، کارهای زمان‌بندی‌شده یا درخواست‌های مکرر admin-ajax.php می‌توانند هم‌زمانی را بالا ببرند. با مشاهده لاگ و Network مرورگر، مسیر پرتکرار را مشخص کنید و سپس از راهنمای کاهش مصرف منابع admin-ajax.php برای بررسی افزونه یا رفتار مشکل‌دار کمک بگیرید. مسدود کردن کورکورانه این مسیر می‌تواند سبد خرید، فرم‌ها و امکانات مدیریت را مختل کند.

ترافیک غیرعادی، Cron هم‌پوشان و کش نامناسب

در لاگ‌ها تعداد درخواست‌ها، User-Agentها، IPهای پرتکرار و مسیرهای پرمصرف را در زمان 508 بررسی کنید. در صورت مشاهده الگوی سوءاستفاده، محدودسازی نرخ درخواست را با احتیاط و پس از تست اعمال کنید. Cronهای هم‌پوشان، اسکن‌های سنگین و پاک‌سازی کش در ساعت پرترافیک نیز باید زمان‌بندی شوند. برای کاهش بار واقعی صفحات عمومی، روش‌های رفع کندی وردپرس را بر اساس علت تأییدشده انتخاب کنید؛ صفحات شخصی‌سازی‌شده و سبد خرید نباید بی‌بررسی کش عمومی شوند.

چه زمانی افزایش منابع هاست منطقی است؟

اگر بعد از رفع افزونه یا درخواست کند، کنترل ترافیک غیرعادی و اصلاح Cron، هنوز در ساعات مصرف معمولی Faultهای EP مرتب افزایش می‌یابند، سقف EP و منابع CPU/PMEM پلن را با میزبان مقایسه کنید. برای تصمیم درباره ظرفیت و امکانات میزبانی، مشخصات پلن‌های هاست وان‌سرور قابل بررسی است؛ اما انتقال سایت یا خرید پلن جدید به‌تنهایی باگ PHP، حمله یا درخواست‌های طولانی را درمان نمی‌کند. هنگام مقایسه، مقدار واقعی EP و شرایط استفاده از منابع را از ارائه‌دهنده استعلام کنید و از حدس زدن ظرفیت صرفاً بر اساس RAM خودداری کنید.

تأیید رفع خطا و بازگردانی تغییرات

پس از هر تغییر، یک بازه مصرف مشابه قبل را زیر نظر بگیرید. در cPanel تعداد EPf را با بازه قبل مقایسه کنید و هم‌زمان پاسخ سایت، زمان بارگذاری و خطاهای وب‌سرور را بسنجید. اگر دسترسی مدیریتی دارید، lveinfo --period 1d -u CPANEL_USER را دوباره اجرا کنید. کاهش Fault در کنار پاسخ موفق سایت، نشانه مؤثرتری از یک بار باز شدن صفحه است.

برای Rollback، پیش از غیرفعال‌سازی افزونه، تغییر Cron، اعمال قانون فایروال یا تنظیم PHP، نسخه پشتیبان و مقادیر قبلی را ثبت کنید. اگر پس از تغییر، پرداخت، ورود کاربران یا درخواست‌های API مختل شد، همان تغییر را بازگردانید و دوباره اندازه‌گیری کنید. افزایش بدون بررسی EP یا NPROC روی سرور شلوغ ممکن است فشار را به سایر حساب‌ها منتقل کند و جایگزین رفع علت نیست.

اشتباه‌های رایج هنگام رفع 508

• 508 را مساوی کمبود RAM فرض کردن: ابتدا EPf را بررسی کنید؛ PMEMf و CPUf شاخص‌های مستقل هستند.
• افزایش بی‌برنامه PHP memory_limit: این تنظیم لزوماً محدودیت EP را تغییر نمی‌دهد.
• بستن همه درخواست‌های admin-ajax یا XML-RPC: بدون شناسایی مسیر مصرف‌کننده ممکن است عملکرد سایت خراب شود.
• اتکا به یک تست موفق: خطای 508 معمولاً مقطعی است و باید با بازه‌های Fault تطبیق داده شود.

نتیجه عملی این است: اول زمان 508 و EP Fault را تطبیق دهید، بعد درخواست کند یا پرتکرار را پیدا و اصلاح کنید، و فقط در صورت مصرف واقعی پایدار به سراغ ارتقای منابع بروید.