بالا بودن عدد CPU به‌تنهایی علت را نمی‌گوید. ممکن است یک پردازش واقعاً محاسبه سنگین انجام دهد، kernel درگیر شبکه باشد، ماشین مجازی CPU کافی از میزبان نگیرد یا load بالا عمدتاً از انتظار I/O آمده باشد. kill کردن اولین process فهرست می‌تواند تراکنش یا write را ناقص کند و معمولاً پاسخ ریشه‌ای نیست.
پاسخ سریع: زمان و اثر کاربر را ثبت کنید؛ سپس تعداد core، load، تفکیک user/system/iowait/steal و processهای پرمصرف را در همان بازه ببینید. PID را به سرویس، request، Query، container یا job زمان‌بندی‌شده وصل کنید. قبل از restart یا تغییر ظرفیت، شواهد و آخرین تغییر را نگه دارید.
آیا واقعاً CPU گلوگاه است؟
کندی سایت لزوماً CPU نیست. صف دیسک، lock دیتابیس، شبکه، DNS یا API بیرونی نیز latency می‌سازند. در top درصد idle پایین همراه user/system بالا با فشار CPU سازگار است؛ iowait بالا مسئله دیگری را نشان می‌دهد. در VPS، steal بالا می‌تواند رقابت با workloadهای میزبان را نشان دهد.
Load Average را درست بخوانید
load average تعداد taskهای runnable و برخی taskهای در انتظار بدون وقفه را خلاصه می‌کند؛ درصد CPU نیست. عدد ۴ روی ماشین ۲ core با عدد ۴ روی ماشین ۱۶ core معنای یکسان ندارد. روند یک، پنج و پانزده دقیقه‌ای جهت تغییر را می‌دهد، اما برای علت به وضعیت CPU و process نیاز دارید.
uptime
nproc
top -b -n 1
ps -eo pid,ppid,user,stat,%cpu,%mem,etime,comm --sort=-%cpu | head -n 20این فرمان‌ها وضعیت را تغییر نمی‌دهند. خروجی top یک snapshot است و ممکن است spike کوتاه را از دست بدهد. نام کاربر، PID و فرمان می‌تواند جزئیات معماری را آشکار کند؛ قبل از اشتراک عمومی آن را پاک‌سازی کنید.
چه زمانی نمونه بگیریم؟
نمونه در زمان آرام به‌تنهایی کمکی به incident ساعت اوج نمی‌کند. dashboard تاریخی یا نمونه‌برداری محدود با timestamp داشته باشید. request rate، latency، error rate، deploy، cron و backup را روی همان timeline قرار دهید. هم‌بستگی نقطه شروع است، نه اثبات علت.
CPU User، System، I/O Wait و Steal
- User: زمان اجرای کد برنامه، PHP، دیتابیس یا پردازش کاربر.
- System: زمان kernel برای syscall، شبکه، filesystem و driver.
- I/O wait: CPU بیکار است اما taskها منتظر I/O هستند؛ خرید CPU بیشتر الزاماً کمک نمی‌کند.
- Steal: زمان گرفته‌شده از VM توسط hypervisor؛ کیفیت host یا سهم CPU را بررسی کنید.
این درصدها در ابزارها و بازه‌های نمونه‌برداری مختلف تفاوت دارند. یک snapshot را به نتیجه قطعی تبدیل نکنید؛ روند و workload را مقایسه کنید.
Process یا Thread پرمصرف
بعد از یافتن PID، parent، زمان اجرا، user و threadها را بررسی کنید. یک process چندنخی می‌تواند بیش از ۱۰۰٪ در نمایش مبتنی بر هر core مصرف کند. command line ممکن است secret داشته باشد؛ بدون انتشار عمومی بررسی شود. PID کوتاه‌عمر را metric یا ابزار نمونه‌برداری بهتر از مشاهده دستی می‌گیرد.
سرویس را به درخواست متصل کنید
برای Nginx زمان request و upstream، برای PHP-FPM slow log کنترل‌شده، برای اپلیکیشن trace و برای دیتابیس slow query را کنار PID قرار دهید. اگر صفحه اصلی سریع ولی یک گزارش CPU را بالا می‌برد، بهینه‌سازی تصویر علت نیست. request ID مشترک از proxy تا برنامه، تشخیص را بسیار کوتاه‌تر می‌کند.
PHP-FPM و WordPress
چند worker پرمصرف می‌توانند ناشی از endpoint سنگین، crawler، wp-cron، افزونه یا Query باشند. افزایش تعداد worker بدون RAM و CPU کافی concurrency مخرب را بیشتر می‌کند. URL و مدت worker را از status/slow log امن پیدا کنید و سپس افزونه یا مسیر درخواست را روی staging بازتولید کنید.
برای بررسی سطح برنامه، راهنمای مصرف CPU وردپرس و تشخیص Slow Query وردپرس مسیر دقیق‌تری ارائه می‌کنند.
MySQL و Queryهای پرهزینه
CPU بالای دیتابیس می‌تواند از full scan، index نامناسب، query تکراری یا concurrency زیاد باشد. process list، slow query log و execution plan را با احتیاط بررسی کنید. log پرحجم روی production می‌تواند I/O و disk را تحت فشار بگذارد؛ زمان و retention محدود تعیین کنید. index را بدون سنجش write cost و backup تغییر ندهید.
Cron، Queue و Jobهای دوره‌ای
اگر spike در ساعت ثابت رخ می‌دهد، cron سیستم، scheduler برنامه، backup، compression، antivirus یا گزارش‌گیری را بررسی کنید. هم‌زمانی چند job می‌تواند ظرفیت را ناگهان مصرف کند. jobها را بدون شناخت قطع نکنید؛ ابتدا owner، قابلیت retry و اثر توقف را مشخص کنید و زمان‌بندی را از ساعت اوج جدا سازید.
Bot، Crawl و ترافیک ناخواسته
افزایش request rate از IP یا مسیر محدود می‌تواند CPU برنامه را مصرف کند، حتی اگر پهنای‌باند پایین باشد. access log را به‌صورت aggregate بررسی کنید و داده شخصی را محافظت کنید. rate limit باید بر مبنای endpoint و رفتار معتبر باشد؛ block گسترده ممکن است کاربر، موتور جست‌وجو یا callback پرداخت را قطع کند.
Container و محدودیت Cgroup
CPU host و container را جدا ببینید. process ممکن است داخل container به quota خود رسیده باشد در حالی که host idle است. throttling، limit و سهم CPU را همراه مصرف مشاهده کنید. حذف limit برای رفع علامت می‌تواند یک سرویس را قادر کند کل host را اشباع کند.
تفاوت Spike کوتاه و Saturation پایدار
کامپایل asset، باز شدن cache یا اجرای یک job ممکن است برای چند ثانیه همه coreها را استفاده کند، بدون اینکه SLA کاربر آسیب ببیند. در مقابل، CPU کمی پایین‌تر اما همراه صف رو‌به‌رشد و latency طولانی می‌تواند جدی‌تر باشد. مدت، تکرار و اثر را کنار درصد ببینید.
برای ظرفیت‌سنجی، نرخ ورود کار را با نرخ تکمیل مقایسه کنید. اگر backlog پس از پایان اوج تخلیه نمی‌شود، سیستم در مرز ناپایدار قرار دارد. میانگین روزانه این وضعیت را پنهان می‌کند؛ بازه‌های کوتاه و percentile پاسخ برای تصمیم مناسب‌ترند.
System CPU بالا
اگر سهم system غیرعادی است، نرخ packet، interrupt، context switch، syscall و storage را بررسی کنید. log flood یا connection storm نیز kernel و logging را درگیر می‌کند. تنظیم kernel از یک نسخه عمومی اینترنت بدون baseline و rollback خطرناک است؛ ابتدا workload و subsystem مشخص شود.
فرایند ناشناس یا احتمال سوءاستفاده
نام عجیب process به‌تنهایی malware را ثابت نمی‌کند. binary path، parent، user، زمان شروع، package ownership و connectionها را حفظ کنید. اگر compromise محتمل است، سیستم را طبق برنامه incident ایزوله کنید و شواهد را از بین نبرید. پاک کردن فایل یا reinstall عجولانه دامنه نفوذ و credentialهای در معرض خطر را نامعلوم می‌گذارد.
ترتیب اقدام کم‌ریسک
- اثر، زمان و تعداد core را ثبت کنید.
- CPU را از iowait و steal جدا کنید.
- PID/thread و سرویس مالک را بیابید.
- آن را به request، query، job یا container وصل کنید.
- آخرین deploy و الگوی ترافیک را مقایسه کنید.
- اصلاح را روی staging یا rollout محدود آزمایش کنید.
- بعد از تغییر، latency، خطا و مصرف را دوباره اندازه بگیرید.
راه‌حل بر اساس علت
- Query بد: اصلاح query/index پس از آزمون و backup
- درخواست تکراری: cache مناسب یا حذف N+1 در لایه برنامه
- crawler: rate control هدفمند و cache
- cron هم‌زمان: توزیع زمان و محدودسازی concurrency
- worker بیش‌ازحد: تنظیم ظرفیت بر اساس RAM/CPU
- CPU ناکافی واقعی: scale عمودی یا افقی پس از رفع ناکارآمدی
- steal مداوم: بررسی plan/provider و شواهد metric
اشتباه‌های رایج
- kill کردن process دیتابیس یا backup بدون شناخت
- افزایش core قبل از یافتن workload
- قضاوت از یک snapshot
- یکی دانستن load و CPU
- نادیده گرفتن iowait و steal
- افزایش workerهای PHP بدون بودجه RAM
- اجرای profiler سنگین و دائمی روی production
- restart و از دست دادن شواهد
پیشگیری و Alert
CPU هر core، load نرمال‌شده، iowait، steal، throttling، request rate، latency و queue را نگه دارید. هشدار spike کوتاه با اشباع پایدار یکسان نیست؛ شرط و مدت مناسب تعریف کنید. برای هر alert یک runbook شامل فرمان‌های خواندنی، owner و مسیر escalation داشته باشید.
چه زمانی کمک تخصصی لازم است؟
اگر CPU پس از restart دوباره بالا می‌رود یا میان PHP، MySQL، container و ترافیک علت روشن نیست، تغییر تصادفی production می‌تواند قطعی بسازد. در مدیریت ماهانه سرور می‌توان metric، log، query و workload را روی یک timeline تحلیل و اصلاح را با rollback اجرا کرد.
پرسش‌های متداول
CPU صددرصد همیشه بد است؟
استفاده کوتاه هنگام job ممکن است طبیعی باشد؛ اشباع پایدار همراه queue، latency یا خطا مسئله است.
Load بالا یعنی CPU بالا؟
نه. taskهای منتظر I/O نیز load را بالا می‌برند؛ وضعیت CPU و I/O را جدا ببینید.
آیا restart مشکل را حل می‌کند؟
ممکن است موقتاً queue یا process را پاک کند، اما علت و شواهد را نیز پنهان می‌کند.
چرا CPU فقط شب بالا می‌رود؟
cron، backup، crawl یا گزارش دوره‌ای محتمل است؛ زمان‌بندی و log همان بازه را تطبیق دهید.