مقالات عمومی
دسته بندی:
خطای Resource Limit Is Reached
خطای Resource Limit Is Reached یعنی حساب هاست شما به سقف منابعی رسیده که در سطح هسته سیستمعامل برایش تعیین شده و وبسرور تا آزاد شدن منابع، درخواستهای تازه را با کد وضعیت 508 رد میکند. این خطا نه به معنای هک شدن سایت است و نه از دست رفتن اطلاعات؛ فقط میگوید سایت شما در بازههای کوتاه بیشتر از سهم خود پردازنده، حافظه، پروسه همزمان یا ورودی/خروجی دیسک خواسته است.
این سقف از کجا میآید؟
روی یک سرور میزبانی اشتراکی دهها حساب کاربری از یک پردازنده و یک حافظه استفاده میکنند. اگر مرزی وجود نداشته باشد، یک افزونه معیوب روی یک سایت کافی است تا کل سرور کند شود. برای همین سرورهای اشتراکی امروز معمولاً روی کلودلینوکس و فناوری LVE اجرا میشوند؛ LVE دور هر حساب یک محیط مجازی سبک میکشد و در سطح هسته تعیین میکند آن حساب حداکثر چقدر منابع مصرف کند. نتیجه این است که وقتی سایتی به سقفش میخورد، فقط همان سایت کند یا موقتاً غیرقابل دسترس میشود و بقیه حسابها سرِ پا میمانند.
پس این پیام یک مکانیزم حفاظتی است، نه یک باگ. کار درست، پیدا کردن این است که کدام سقف پر شده و چه چیزی آن را پر کرده است.
هر محدودیت چه چیزی را میسنجد؟
| محدودیت | چه چیزی را میسنجد | وقتی پر شود چه میشود |
CPU (SPEED) |
سهم پردازش حساب شما، معمولاً بهصورت درصد یک هسته | اجرای اسکریپتها کُند میشود، صفحه دیر میآید |
EP (Entry Processes) |
تعداد درخواستهای PHP که همزمان در حال اجرا هستند | درخواستهای اضافه با خطای ۵۰۸ رد میشوند |
NPROC |
کل پروسههای حساب، شامل کرانجابها و SSH | پروسه جدید ساخته نمیشود و درخواست با ۵۰۸ رد میشود |
PMEM |
حافظه فیزیکی مصرفی همه پروسههای حساب | پروسه با خطای حافظه بسته میشود |
IO / IOPS |
پهنایباند دیسک (مثلاً مگابایت بر ثانیه) و تعداد عملیات دیسک | خواندن و نوشتن فایل و دیتابیس کند میشود |
مهمترین نکته این جدول تفاوت ستون آخر است. پیام ۵۰۸ مستقیماً از سقف EP یا NPROC میآید، نه از سقف پردازنده؛ پر شدن CPU و IO سایت را کند میکند اما درخواست را با ۵۰۸ رد نمیکند. یعنی وقتی این خطا را میبینید، مسئله معمولاً «سنگین بودن» سایت نیست، «همزمان رسیدن» درخواستهایی است که هر کدام چند ثانیه طول میکشند.
خواندن نمودار مصرف
قبل از هر کاری بدانید سقف شما چقدر است؛ مثلاً صفحه هاست لینوکس ایران مقدار CPU، RAM و I/O پلنها را صریح نوشته است و همین عددها مبنای مقایسه شماست. بعد در cPanel به بخش Resource Usage بروید. دو چیز را ببینید: نمودار مصرف در ۲۴ ساعت گذشته، و ستون Faults که میگوید هر محدودیت چند بار به سقف خورده است. اگر Faults فقط جلوی EP عدد دارد، دنبال ترافیک همزمان و صفحههای کشنشده بگردید؛ اگر جلوی IO است، دنبال کوئریهای سنگین یا بکاپگیری؛ اگر جلوی PMEM است، دنبال یک افزونه پرمصرف. ساعت دقیق اوج مصرف را یادداشت کنید، چون گام بعدی مقایسه همان ساعت با لاگهاست.
تشخیص: چند دستور که واقعاً جواب میدهند
این دستورها به دسترسی SSH یا ابزار Terminal در cPanel نیاز دارند. ابتدا لاگ خطا را ببینید؛ نام افزونه یا فایل مقصر معمولاً همانجا نوشته شده است:
tail -n 200 ~/public_html/error_logسپس ببینید در ساعت اوج، ترافیک از کجا آمده. پرتکرارترین آیپیها:
awk '{print $1}' ~/access-logs/example.com | sort | uniq -c | sort -rn | head -20و پرتکرارترین عاملهای کاربری، که رباتها را لو میدهد:
awk -F'"' '{print $6}' ~/access-logs/example.com | sort | uniq -c | sort -rn | head -20در وردپرس، دو منبع کلاسیک مصرف را هم بررسی کنید. فهرست زمانبندیهای داخلی:
wp cron event listو گزینههای autoload که در هر درخواست از دیتابیس خوانده میشوند:
wp db query "SELECT option_name, LENGTH(option_value) AS s FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on') ORDER BY s DESC LIMIT 20;"دو دستور آخر به WP-CLI نیاز دارند که روی هر هاست اشتراکی نصب نیست؛ اگر در دسترس نبود، همین دو بررسی را با افزونههای مدیریت کران و بازبینی جدول wp_options از phpMyAdmin هم میشود انجام داد. توجه کنید که از وردپرس ۶٫۶ به بعد ستون autoload مقادیر تازهای مثل on و auto هم میگیرد؛ کوئریهای قدیمی که فقط autoload='yes' را میبینند دیگر تصویر کاملی نمیدهند. اگر مجموع این ردیفها چند صد کیلوبایت شد، همانجا یک منبع دائمی مصرف حافظه دارید.
رفع، بر اساس علت
- افزونه یا ماژول پرمصرف: بهجای غیرفعال کردن کورکورانه همه چیز، افزونهای مثل Query Monitor را روی یک نسخه آزمایشی فعال کنید تا ببینید کدام افزونه بیشترین زمان و کوئری را میگیرد. افزونههای آماردهی داخلی، فروشگاهساز بدون کش و افزونههای «مطالب مرتبط» از مقصرهای رایجاند.
- وردپرس بدون کش: اگر هر بازدید یک اجرای کامل PHP باشد، سقف
EPبا ترافیک متوسط هم پر میشود. کش صفحه را فعال کنید تا خروجی HTML آماده تحویل داده شود؛ برای این خطا معمولاً همین یک کار بیشترین اثر را دارد. اگر سایت وردپرسی پربازدید دارید، پلنهای هاست وردپرس ایران هم سقف CPU، RAM و I/O بالاتری اعلام کردهاند. - هجوم ربات: خزندههای تهاجمی و اسکنرها را با قوانین فایروال یا
User-agentمحدود کنید. حمله رویwp-login.phpوxmlrpc.phpهم دقیقاً همین خطا را میسازد؛ اگر از XML-RPC استفاده نمیکنید ببندیدش. - کرانجاب فراری:
wp-cronپیشفرض روی هر بازدید اجرا میشود. آن را باdefine('DISABLE_WP_CRON', true);درwp-config.phpخاموش کنید و بهجایش یک کرانجاب واقعی هر ۱۵ دقیقه در cPanel بسازید کهwp-cron.phpرا صدا بزند. - نسخه PHP قدیمی: نسخههای
5.6و7.xسالهاست پشتیبانی نمیشوند و8.0و8.1هم دیگر به پایان عمر رسیدهاند؛ همهشان محسوساً کندتر و پرمصرفترند و وصله امنیتی نمیگیرند. از طریق PHP Selector یا MultiPHP Manager به8.3یا بالاتر بروید وOPcacheرا روشن نگه دارید. قبل از تغییر نسخه، سازگاری قالب و افزونهها را روی یک نسخه آزمایشی امتحان کنید.
چیزی که معمولاً بهتنهایی جواب نمیدهد
توصیه قدیمیِ «کلودفلر را روشن کن تا مصرف کم شود» نصفه است. CDN بهصورت پیشفرض فایلهای ایستا مثل تصویر و CSS را کش میکند، اما صفحههای HTML داینامیک را کش نمیکند؛ یعنی همان درخواستهایی که PHP اجرا میکنند و سقف EP را پر میکنند، همچنان به سرور میرسند. تا وقتی قانون کش برای HTML تعریف نکنید یا کش صفحه روی خود سایت فعال نباشد، فشار کم نمیشود.
افزایش صرف فضای دیسک هم کمکی نمیکند؛ فضای میزبانی و سقف پردازش دو چیز کاملاً جدا هستند و بزرگتر شدن یکی، دیگری را تکان نمیدهد.
پیشگیری
کش صفحه را دائمی نگه دارید، تصاویر را بهینه و با اندازه درست آپلود کنید، افزونههای بلااستفاده را حذف کنید (نه فقط غیرفعال)، بکاپگیری سنگین را به ساعت کمترافیک ببرید و ماهی یکبار نمودار Resource Usage را نگاه کنید. دلایل عمومیتر را هم در نوشته مصرف زیاد منابع سایت یا سرور بررسی کنید.
کِی باید بپذیریم هاست اشتراکی کوچک شده است؟
جواب صادقانه همیشه «تنظیمات را بهتر کن» نیست. اگر بعد از فعال کردن کش، پاکسازی افزونهها و بهروزرسانی PHP باز هم روزانه Faults میبینید، یا اگر سایت شما ذاتاً داینامیک است (فروشگاه با سبد خرید، پنل کاربری، API پرترافیک) و کش صفحه برایش معنا ندارد، سایت از هاست اشتراکی عبور کرده است. در این حالت انتقال به سرور مجازی ابری ایران منابع را بهصورت اختصاصی در اختیار شما میگذارد و دیگر سقف LVE بالای سرتان نیست. البته در ازای آن، مدیریت سرور هم بر عهده خودتان است؛ روی سرور مجازی یا اختصاصی میتوانید با ابزار htop پردازش پرمصرف را زنده ببینید، کاری که روی هاست اشتراکی امکانپذیر نیست.
ارتقا به پلن بالاتر هم گزینه معتبری است و راهنمای امکان ارتقای فضای میزبانی مسیرش را توضیح میدهد. فقط اول علت را پیدا کنید؛ ارتقا بدون تشخیص، معمولاً همان مشکل را چند هفته دیرتر برمیگرداند.
