CPU صددرصد فقط می‌گوید پردازنده مشغول است؛ نمی‌گوید کدام درخواست یا سرویس مقصر است. ترافیک واقعی، bot، wp-cron، loop یک افزونه، PHP workerها، query دیتابیس یا حتی backup و فشرده‌سازی می‌توانند الگوی مشابه بسازند. ری‌استارت ممکن است موقتاً نمودار را پایین بیاورد و هم‌زمان مهم‌ترین شواهد را از بین ببرد.
اقدام سریع: زمان شروع، processهای پرمصرف، load، ترافیک و log درخواست‌ها را ثبت کنید. ابتدا سرویس حیاتی را با محدودسازی هدفمند عامل مخرب حفظ کنید؛ سپس URL، job یا query متناظر را پیدا کنید. مسدود کردن همه کاربران، حذف افزونه یا افزایش بی‌حساب سرور تشخیص محسوب نمی‌شود.
آیا واقعاً CPU گلوگاه است؟
عدد CPU را کنار load average، تعداد core، iowait، memory، swap و latency ببینید. load بالا می‌تواند شامل انتظار I/O باشد. در هاست اشتراکی نیز throttling یا سهم CPU ممکن است با یک VPS اختصاصی قابل مقایسه نباشد. بازه یک‌دقیقه‌ای و پانزده‌دقیقه‌ای نشان می‌دهد spike کوتاه است یا فشار پایدار.
uptime
top
ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpuاین فرمان‌ها read-only هستند. snapshot را چند بار در زمان حادثه بگیرید؛ یک نمونه ممکن است job کوتاه را بیش‌ازحد مهم نشان دهد. command line و نام کاربران سیستم را پیش از اشتراک عمومی پاک کنید.
کدام process CPU را مصرف می‌کند؟
| process غالب | مسیر بررسی |
|---|---|
| php-fpm | URL، access log، slowlog، افزونه و درخواست |
| mysqld/mariadbd | query فعال، slow query، lock و index |
| cron / php CLI | نام hook، job، صف و هم‌پوشانی اجرا |
| backup/compression | زمان‌بندی، priority و پنجره اجرا |
| process ناشناس | مسیر executable، parent و بررسی امنیتی |
اگر process ناشناخته یا اجرای غیرمنتظره می‌بینید، آن را فوراً فایل «ویروس» فرض نکنید و کورکورانه حذف نکنید. شواهد، مسیر، مالک، parent process و persistence را ثبت و بررسی امنیتی انجام دهید.
ترافیک واقعی، bot یا حمله؟
access log را بر اساس URL، IP، user-agent، status و نرخ درخواست خلاصه کنید. یک endpoint مثل جستجو، login، XML-RPC، REST یا URL بدون cache ممکن است بار نامتناسب ایجاد کند. IP تنها معیار هویت نیست و user-agent قابل جعل است؛ الگو و اثر درخواست مهم‌اند.
محدودسازی نرخ در CDN یا وب‌سرور باید روی مسیر مشخص و با تست کاربران واقعی اعمال شود. مسدودسازی جغرافیایی یا challenge سراسری ممکن است crawler مجاز، webhook، درگاه پرداخت یا API را مختل کند. credential و query string حساس را در گزارش عمومی منتشر نکنید.
PHP-FPM و درخواست پرمصرف
اگر PHP workerها غالب‌اند، access log دارای زمان پاسخ و PHP-FPM slowlog می‌تواند درخواست کند را به stack نزدیک کند. slowlog باید با timeout و مسیر امن تنظیم شود و overhead آن سنجیده شود. افزایش worker باعث پردازش هم‌زمان بیشتر می‌شود، اما اگر CPU اشباع است ممکن است صف رقابت را بدتر کند.
صفحه‌ای که cache می‌شود ممکن است برای کاربران ناشناس سبک و برای کاربر واردشده سنگین باشد. checkout، wp-admin، جستجو و API را جدا بسنجید. برای پیشخوان، راهنمای کندی wp-admin را دنبال کنید.
wp-cron و jobهای هم‌پوشان
backup، اسکن، ارسال ایمیل، sync محصول و پاک‌سازی ممکن است هم‌زمان اجرا شوند. cron قفل‌نشده یا jobی که بیش از interval خود طول می‌کشد می‌تواند چند نمونه هم‌پوشان بسازد. نام hook، زمان شروع، duration و نتیجه آخر را ثبت کنید.
اجرای دستی همه eventها یا حذف صف بدون شناخت اثر، خطر تکرار ایمیل و از دست رفتن کار دارد. job را batch کنید، lock و retry را اصلاح و کار سنگین را به زمان مناسب منتقل کنید. جایگزینی wp-cron با system cron فقط وقتی درست است که فراخوانی، مانیتورینگ و جلوگیری از overlap طراحی شده باشد.
MySQL چگونه CPU می‌گیرد؟
query بدون index، جستجوی meta، گزارش بزرگ، sort روی disk و فراخوانی پرتکرار می‌تواند CPU دیتابیس را بالا ببرد. process list فقط وضعیت لحظه‌ای است؛ slow query log و digest فراوانی تصویر بهتری می‌دهد. query را با plan و تعداد rowها بررسی کنید و index را ابتدا روی clone بسازید؛ index اضافی هزینه write و فضا دارد.
اگر خطای lock یا schema نیز وجود دارد، راهنمای خطاهای MySQL وردپرس را ببینید. restart دیتابیس query بد را اصلاح نمی‌کند و ممکن است cache گرم را از بین ببرد.
افزونه یا قالب را چگونه isolate کنیم؟
- آخرین deployment، update و تغییر تنظیمات را ثبت کنید.
- URL/job تولیدکننده بار را در staging بازتولید کنید.
- با profiler یا Query Monitor، hook و caller را پیدا کنید.
- افزونه‌ها را کنترل‌شده گروه‌بندی و عامل را تکی تأیید کنید.
- با نسخه سازگار rollback یا تنظیم/کد عامل را اصلاح کنید.
- همان workload را قبل و بعد اندازه بگیرید.
غیرفعال‌سازی همه افزونه‌ها روی production می‌تواند سرویس تجاری را بشکند. برای مشاهده fatalها از ثبت امن debug.log استفاده کنید، نه نمایش خطا به بازدیدکننده.
مهار موقت بدون پنهان کردن علت
اگر سایت در آستانه قطعی است، rate limit هدفمند، توقف موقت job مشخص، کاهش concurrency عامل یا فعال‌سازی cache صحیح می‌تواند زمان بخرد. هر اقدام باید owner، زمان انقضا و rollback داشته باشد. افزایش فوری منابع نیز گاهی برای حفظ سرویس لازم است، اما شواهد را قبل از تغییر نگه دارید و آن را جای اصلاح ریشه‌ای نگذارید.
اشتباه‌های رایج
- reboot قبل از ذخیره process و logها
- مسدود کردن سراسری بدون استثنای payment و webhook
- افزایش PHP worker روی CPU اشباع
- پاک کردن cron queue یا دیتابیس بدون backup
- نصب چند افزونه cache در میانه حادثه
- نتیجه‌گیری از یک snapshot کوتاه
پیشگیری و مانیتورینگ
CPU، load، queue PHP، latency، error rate و ترافیک endpointها را مانیتور کنید. alert باید قبل از اشباع پایدار و با مدت مناسب فعال شود تا spike بی‌اهمیت هشدار نسازد. jobهای سنگین را زمان‌بندی، update را روی staging آزمایش و ظرفیت را با ترافیک واقعی بازبینی کنید.
چه زمانی مداخله تخصصی لازم است؟
اگر CPU پس از کاهش ترافیک همچنان بالاست، چند process درگیرند یا مشکل فقط زیر concurrency رخ می‌دهد، آزمون‌وخطا روی production پرریسک است. سرویس افزایش سرعت وردپرس می‌تواند از process و access log تا PHP و query منبع مصرف را مشخص کند.
پرسش‌های متداول
آیا CPU صددرصد همیشه بد است؟
spike کوتاه ممکن است طبیعی باشد؛ اشباع پایدار همراه با صف، latency و خطا نشانه مشکل ظرفیت یا workload است.
آیا ارتقای سرور مشکل را حل می‌کند؟
ظرفیت بیشتر زمان می‌خرد، اما loop، bot یا query معیوب معمولاً با رشد ترافیک دوباره ظاهر می‌شود.
چرا CPU شب‌ها بالا می‌رود؟
backup، scan، cron و sync زمان‌بندی‌شده را با همان بازه مقایسه کنید.