مصرف بالای منابع هاست یک مشکل واحد نیست. پرشدن فضای دیسک، کمبود حافظه و رسیدن درخواست‌ها به محدودیت هم‌زمانی، علت و راه‌حل متفاوت دارند. ابتدا شاخصی را که به سقف رسیده پیدا کنید؛ عبارت «منابع زیاد مصرف شده» به‌تنهایی برای تصمیم‌گیری کافی نیست.
شاخص‌های مصرف بالای منابع هاست
| شاخص | معنای کاربردی |
|---|---|
| CPU / SPEED | سهم توان پردازش؛ در CloudLinux درصد می‌تواند نسبت به یک هسته باشد. |
| PMEM | حافظهٔ فیزیکی مورد استفادهٔ پردازش‌های حساب. |
| I/O و IOPS | نرخ انتقال دیسک و تعداد عملیات ورودی/خروجی؛ با ترافیک شبکه فرق دارند. |
| EP | ورود هم‌زمان به محیط محدودشده؛ تفسیر دقیق وابسته به وب‌سرور است. |
| NPROC | محدودیت تعداد پردازش‌ها؛ با EP یکسان نیست. |
از زمان خطا شروع کنید
در ابزار منابع میزبان، بازه‌ای را انتخاب کنید که کاربر کندی یا خطا دیده است. سقف، مقدار مصرف و شمارندهٔ Fault را کنار هم ببینید. یک جهش کوتاه الزاماً مشکل دائمی نیست و میانگین پایین نیز رسیدن لحظه‌ای به سقف را رد نمی‌کند. منطقهٔ زمانی گزارش‌ها باید یکسان باشد.
علت‌های رایج را به شواهد وصل کنید
- درخواست‌های کند: زمان پاسخ دیتابیس و سرویس‌های خارجی را بررسی کنید.
- کارهای زمان‌بندی‌شده: اجرای هم‌پوشان بک‌آپ، ایمپورت و کرون را جدا کنید.
- افزونه یا قالب: تغییرات اخیر را با شروع فشار تطبیق دهید.
- ربات یا حمله: مسیرها، نرخ درخواست و گزارش امنیتی را بررسی کنید؛ هر IP پرتکرار مهاجم نیست.
کاهش فشار بدون خراب‌کردن سایت
کش مناسب می‌تواند پردازش تکراری را کم کند، اما صفحات شخصی، سبد خرید و حساب کاربری نباید اشتباه کش شوند. زمان‌بندی کارهای سنگین را بر اساس نیاز واقعی تنظیم کنید؛ فاصلهٔ ثابت پانزده دقیقه برای همهٔ کرون‌ها مناسب نیست. تعمیر همهٔ جدول‌های دیتابیس نیز درمان عمومی مصرف CPU نیست.
تغییر نام پوشهٔ wp-admin، مجوز یکسان 400 برای تمام فایل‌ها یا خاموش‌کردن ابزار امنیتی راه‌حل عمومی بهینه‌سازی نیست. CAPTCHA هم عبور همهٔ ربات‌ها را ناممکن نمی‌کند. علت را اصلاح کنید و اثر هر تغییر را در همان شاخص مرتبط ببینید.
ارتقا چه زمانی کمک می‌کند؟
وقتی بار ضروری و بهینه‌شده همچنان از سهمیهٔ واقعی بالاتر است، افزایش همان منبع می‌تواند مفید باشد. نام تجاری پلن، مقدار دقیق CPU یا RAM را ثابت نمی‌کند؛ مشخصات سرویس را بررسی کنید. مستند CloudLinux تفاوت محدودیت‌ها و رفتار آن‌ها را توضیح می‌دهد؛ همهٔ میزبان‌ها الزاماً همین فناوری را ندارند.
مطالعهٔ مرتبط
بازبینی فنی: ۱۳ آبان ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
