بالا رفتن مصرف CPU همیشه نشانه خرابی سرور نیست؛ گاهی پردازنده مشغول انجام کار مفید است و گاهی یک کوئری ناکارآمد، حلقه معیوب یا موج درخواست‌های غیرضروری منابع را مصرف می‌کند. مسئله زمانی جدی می‌شود که این مصرف با افزایش زمان پاسخ، تشکیل صف، محدود شدن منابع یا خطاهای سرویس همراه باشد.
برای رفع مشکل، نباید از همان ابتدا سراغ ارتقای سرور یا ری‌استارت سرویس‌ها رفت. ابتدا باید مشخص کنیم چه چیزی مصرف را بالا برده، کدام بخش واقعاً گلوگاه است و آیا ظرفیت قابل استفاده با عددی که در پنل می‌بینیم یکسان است یا نه. این راهنما مسیر تشخیص را از نمودار منابع تا پردازش، درخواست و کد مسئله‌ساز دنبال می‌کند.
مصرف بالای CPU دقیقاً چه معنایی دارد؟
درصد CPU بدون شناخت ابزار اندازه‌گیری و محدوده منابع، ممکن است گمراه‌کننده باشد.
در لینوکس، مقدار CPU یک پردازش در top لزوماً به ۱۰۰ درصد محدود نیست. در حالت Irix، پردازشی چندریسمانی که معادل دو پردازنده منطقی را کامل مشغول کرده باشد، می‌تواند حدود ۲۰۰ درصد مصرف نشان دهد. در حالت Solaris، این مقدار بر تعداد پردازنده‌ها تقسیم می‌شود. بنابراین، قبل از مقایسه اعداد باید شیوه نمایش ابزار را بشناسید.
در هاست اشتراکی نیز عدد ۱۰۰ درصد ممکن است به معنی استفاده کامل از سهمیه حساب شما باشد، نه اشباع پردازنده کل سرور. در کانتینرها هم ممکن است میزبان ظرفیت آزاد داشته باشد، اما برنامه به سقف سهمیه CPU خود رسیده و محدود شده باشد.
آیا عبور مصرف CPU از ۸۰ درصد خطرناک است؟
آستانه ثابتی برای همه سرویس‌ها وجود ندارد. برای یک پردازش دسته‌ای، مصرف نزدیک به ظرفیت کامل می‌تواند مطلوب باشد؛ برای API حساس به تأخیر، همان وضعیت ممکن است حاشیه لازم برای جذب جهش ترافیک را از بین ببرد.
به‌جای تکیه بر یک درصد ثابت، این موارد را کنار هم بررسی کنید:
- مصرف در چه بازه‌ای بالا مانده است؟
- تأخیر صدک ۹۵ یا ۹۹ درخواست‌ها چه تغییری کرده است؟
- نرخ خطا و طول صف افزایش یافته‌اند؟
- مصرف با رشد ترافیک تناسب دارد؟
- یک هسته اشباع شده یا همه هسته‌ها؟
- محدودسازی CPU رخ می‌دهد؟
اصل مفید این است: مصرف منابع، اشباع و خطاها را با هم بسنجید. این همان چارچوبی است که روش USE برای عیب‌یابی عملکرد پیشنهاد می‌کند.
پیش از هر اقدامی، این چهار وضعیت را از هم جدا کنید
| وضعیت | نشانه‌های قابل بررسی | مسیر اولیه عیب‌یابی |
|---|---|---|
| مصرف واقعی CPU توسط برنامه | افزایش زمان CPU در فضای کاربر، پردازش یا ریسمان پرمصرف | پروفایل کد، بررسی کوئری‌ها و مسیرهای پرتکرار |
| انتظار برای ورودی‌وخروجی | افزایش تأخیر ذخیره‌ساز، پردازش‌های مسدود و احتمال افزایش iowait |
بررسی دیسک، دیتابیس و فشار حافظه |
| محدودیت سهمیه | افزایش شمارنده‌های throttling، رسیدن مصرف حساب به سقف مجاز | بررسی محدودیت سرویس یا cgroup |
| محدودیت در محیط مجازی | افزایش پایدار steal همراه با افت عملکرد |
بررسی ظرفیت میزبان با ارائه‌دهنده |
iowait درصد CPU مصرف‌شده توسط دیسک نیست؛ به زمانی اشاره دارد که CPU بیکار بوده و درخواست I/O معوق وجود داشته است. همچنین steal زمان انتظار ناخواسته پردازنده مجازی هنگام سرویس‌دهی هایپروایزر به پردازنده‌های مجازی دیگر را نشان می‌دهد. هیچ‌کدام به‌تنهایی تشخیص نهایی نیستند.
Load Average نیز درصد مصرف CPU نیست. در لینوکس، علاوه بر کارهای آماده اجرا، کارهای در انتظار غیرقابل‌وقفه، مانند برخی انتظارهای I/O، می‌توانند در آن نقش داشته باشند. در نتیجه، Load بالا الزاماً با ارتقای CPU برطرف نمی‌شود.
دلایل اصلی بالا رفتن مصرف CPU و راهکار هرکدام
۱. افزایش درخواست‌ها یا تغییر جنس ترافیک
تعداد بازدید به‌تنهایی هزینه پردازشی را توضیح نمی‌دهد. هزار درخواست به یک فایل کش‌شده ممکن است سبک‌تر از چند درخواست هم‌زمان به جست‌وجوی پیچیده یا تولید گزارش باشد.
برای تشخیص، نرخ درخواست را در کنار این شاخص‌ها قرار دهید:
- مسیر یا endpoint درخواست؛
- زمان پاسخ و وضعیت HTTP؛
- نسبت پاسخ‌های کش‌شده؛
- درخواست‌های احراز هویت‌شده؛
- تعداد اجرای عملیات پرهزینه.
اگر CPU با ترافیک رشد کرده اما هزینه هر درخواست تقریباً ثابت مانده است، احتمال کمبود ظرفیت بیشتر می‌شود. اگر نرخ درخواست ثابت است ولی مصرف افزایش یافته، تغییر کد، افت کارایی کش یا گران‌تر شدن کوئری‌ها را بررسی کنید.
راهکار: مسیرهای پرهزینه را بهینه کنید، برای عملیات مناسب کش بگذارید و کارهایی مثل تولید گزارش یا تبدیل فایل را به صف پس‌زمینه منتقل کنید. توجه داشته باشید که انتقال کار به صف، هزینه CPU را حذف نمی‌کند؛ فقط امکان کنترل زمان اجرا و هم‌زمانی را فراهم می‌کند.
۲. کد ناکارآمد، حلقه معیوب و پردازش تکراری
حلقه‌های بدون شرط خروج درست، محاسبات تکراری، پردازش بزرگ JSON، تولید تصویر و فشرده‌سازی می‌توانند زمان CPU زیادی مصرف کنند. در برنامه‌های مدیریت‌شده، فشار تخصیص حافظه و فعالیت شدید جمع‌آوری زباله نیز باید بررسی شود.
نکته مهم این است که زمان اجرای طولانی با زمان CPU بالا یکسان نیست. درخواست ممکن است بیشتر عمر خود را منتظر دیتابیس، شبکه یا قفل بماند.
راهکار:
- پردازش و سپس ریسمان پرمصرف را پیدا کنید.
- در بازه‌ای کوتاه و نماینده، پروفایل نمونه‌برداری بگیرید.
- توابع دارای سهم بالاتر از زمان CPU را بررسی کنید.
- تغییر را با بار مشابه قبل و بعد مقایسه کنید.
در محیط عملیاتی، پروفایل‌گیری را با ابزار سازگار با زبان، سربار مشخص و زمان محدود انجام دهید؛ فعال کردن دیباگ سنگین هنگام اشباع می‌تواند وضعیت را بدتر کند.
۳. کوئری‌های پرهزینه و الگوی N+1
نبود ایندکس مناسب، خواندن ردیف‌های بسیار بیشتر از خروجی موردنیاز، مرتب‌سازی بزرگ و اجرای مکرر کوئری‌ها می‌توانند هزینه پردازش دیتابیس را افزایش دهند. الگوی N+1 نیز تعداد زیادی کوئری کوچک تولید می‌کند که هزینه تجمیعی آن‌ها ممکن است قابل توجه باشد. این عوامل در منابع کاربردی بررسی مصرف CPU هاست نیز مطرح شده‌اند.
راهکار:
- کوئری‌ها را با ابزارهای ثبت آمار یا slow query log شناسایی کنید.
- فقط طولانی‌ترین کوئری را نبینید؛ فراوانی اجرا و هزینه تجمیعی مهم‌اند.
- طرح اجرا را با ابزار مناسب موتور دیتابیس بررسی کنید.
- ایندکس را بر اساس فیلترها، اتصال‌ها و الگوی واقعی دسترسی طراحی کنید.
- برای رفع N+1 از دریافت گروهی داده یا بارگذاری ارتباطات به‌شکل کنترل‌شده استفاده کنید.
هشدار: در موتورهایی مانند PostgreSQL و MySQL، دستور EXPLAIN ANALYZE کوئری را واقعاً اجرا می‌کند. آن را برای کوئری سنگین یا تغییردهنده داده، بدون شناخت رفتار نسخه و محیط، روی سرویس عملیاتی اجرا نکنید.
ایندکس بیشتر هم همیشه بهتر نیست؛ هزینه نوشتن و نگهداری را افزایش می‌دهد. همچنین کوئری کند ممکن است منتظر قفل یا دیسک باشد و لزوماً مصرف‌کننده اصلی CPU نباشد.
۴. نبود کش، افت نرخ برخورد یا انقضای هم‌زمان
وقتی پاسخ تکراری هر بار از ابتدا تولید می‌شود، برنامه و دیتابیس کار غیرضروری انجام می‌دهند. اما وجود یک سرویس کش به‌تنهایی کافی نیست؛ باید بدانید چه بخشی از درخواست‌ها واقعاً از آن استفاده می‌کنند.
سه لایه را از هم جدا کنید:
- کش صفحه یا پاسخ: جلوگیری از تولید دوباره پاسخ‌های قابل اشتراک؛
- کش داده یا شیء: کاهش واکشی و محاسبه تکراری؛
- کش بایت‌کد مانند OPcache: کاهش نیاز به کامپایل مجدد کد PHP.
انقضای هم‌زمان داده‌های پرترافیک نیز می‌تواند باعث هجوم درخواست‌ها برای بازسازی کش شود؛ وضعیتی که به Cache Stampede معروف است.
راهکار: نرخ برخورد کش، سیاست انقضا و علت bypass را بررسی کنید. برای داده‌های مناسب، قفل بازسازی، پراکندگی زمان انقضا یا ارائه موقت نسخه قدیمی می‌تواند از بازسازی هم‌زمان جلوگیری کند.
پاک کردن مکرر کش راهکار عمومی کاهش CPU نیست و ممکن است با ایجاد کش سرد، مصرف را افزایش دهد. همچنین CDN فقط برای درخواست‌هایی که در لبه پاسخ می‌دهد، از پردازش مبدأ می‌کاهد؛ فعال بودن آن به‌خودی‌خود به معنی کاهش هزینه درخواست‌های پویای غیرقابل‌کش نیست.
۵. هم‌پوشانی کرون‌جاب‌ها و کارهای پس‌زمینه
بکاپ‌گیری، فشرده‌سازی، پردازش تصویر، همگام‌سازی داده و ارسال گروهی پیام ممکن است هم‌زمان با اوج ترافیک اجرا شوند. اگر زمان اجرای یک کار از فاصله زمان‌بندی آن بیشتر باشد، احتمال هم‌پوشانی اجراها نیز وجود دارد.
راهکار:
- مدت اجرا و زمان شروع هر کار را ثبت کنید.
- برای کارهای غیرقابل اجرای هم‌زمان، قفل مناسب در نظر بگیرید.
- هم‌زمانی workerها را محدود کنید.
- داده‌ها را در دسته‌های کنترل‌شده پردازش کنید.
- کارهای سنگین را، در صورت امکان، از سرویس پاسخ‌گوی وب جدا کنید.
انتقال زمان اجرا به نیمه‌شب فقط وقتی مفید است که آن ساعت واقعاً کم‌ترافیک باشد و با بکاپ یا نگهداری دیتابیس تداخل نداشته باشد.
۶. افزونه‌ها و قابلیت‌های پرهزینه وردپرس
در وردپرس، تعداد افزونه‌ها معیار کافی نیست. یک افزونه ممکن است در هر درخواست کوئری پرهزینه اجرا کند، در حالی که چند افزونه دیگر سربار ناچیزی داشته باشند.
موارد قابل بررسی عبارت‌اند از:
- درخواست‌های مکرر به
admin-ajax.php؛ - مسیرهای REST API؛
- اجرای وظایف زمان‌بندی‌شده؛
- جست‌وجو و فیلترهای فروشگاهی؛
- آمارگیری یا ثبت رویداد سنگین؛
- کد سمت سرور قالب.
راهکار: ابتدا درخواست و مؤلفه مسئله‌ساز را با لاگ یا ابزار تشخیصی پیدا کنید. سپس در محیط آزمایشی یا بازه کنترل‌شده، همان مؤلفه را تغییر دهید.
غیرفعال کردن یک‌باره همه افزونه‌ها روی فروشگاه زنده می‌تواند پرداخت، امنیت یا منطق کسب‌وکار را مختل کند. خاموش کردن Heartbeat یا WP-Cron نیز نباید بدون بررسی وابستگی‌ها و آماده بودن جایگزین مناسب انجام شود.
۷. ربات‌ها، حملات لایه کاربرد و بدافزار
ربات‌هایی که مرتب مسیرهای پویا را فراخوانی می‌کنند، تلاش‌های پرتعداد ورود و حملات لایه کاربرد می‌توانند CPU را درگیر کنند. در مقابل، حمله حجمی ممکن است ابتدا پهنای باند یا تجهیزات شبکه را اشباع کند؛ بنابراین هر DDoS الزاماً با CPU صددرصد همراه نیست.
اگر پردازش ناشناخته، ارتباط خروجی غیرمنتظره یا تغییر مشکوک فایل‌ها دیده می‌شود، احتمال نفوذ را نیز بررسی کنید.
راهکار:
- نرخ درخواست را بر اساس مسیر و الگوی رفتاری تحلیل کنید.
- محدودسازی نرخ را متناسب با endpoint اعمال کنید.
- در معماری پشت CDN یا پراکسی، استخراج IP واقعی را فقط برای پراکسی‌های مورد اعتماد تنظیم کنید.
- در رخداد امنیتی، شواهد را حفظ و میزبان را طبق برنامه پاسخ‌گویی به رخداد مهار کنید.
مسدود کردن صرفاً بر اساس User-Agent قابل اتکا نیست. همچنین کشتن یک پردازش مشکوک، بدون رفع مسیر نفوذ و ماندگاری مهاجم، درمان کامل محسوب نمی‌شود.
۸. تنظیم نامناسب هم‌زمانی یا کمبود ظرفیت
افزایش تعداد workerها همیشه توان پاسخ‌گویی را بالا نمی‌برد. وقتی CPU اشباع است، worker بیشتر ممکن است فقط رقابت برای پردازنده، مصرف حافظه و تعداد اتصال‌های دیتابیس را افزایش دهد.
در PHP-FPM، گزینه pm.max_children سقف تعداد فرایندهای فرزند و در نتیجه تعداد درخواست‌های هم‌زمان قابل سرویس‌دهی را تعیین می‌کند. تنظیم آن باید با ظرفیت CPU، مصرف حافظه، رفتار درخواست‌ها و ظرفیت دیتابیس سازگار باشد.
راهکار: هم‌زمانی را با آزمون بار تنظیم کنید. اگر گلوگاه تک‌ریسمانی است، افزودن هسته به‌تنهایی الزاماً آن را حل نمی‌کند. اگر بار قابلیت موازی‌سازی دارد و گلوگاه مشترک دیگری وجود ندارد، افزایش ظرفیت یا توزیع بار می‌تواند مؤثر باشد.
راهنمای عملی بررسی مصرف CPU در سرور لینوکسی
محیط اجرا: سرور لینوکسی دارای دسترسی SSH. دستورهای زیر برای مشاهده وضعیت‌اند و تنظیمات سرویس را تغییر نمی‌دهند. ابزارهای mpstat و pidstat معمولاً در بسته sysstat قرار دارند. برای مشاهده پردازش‌های سایر کاربران ممکن است مجوز بیشتری لازم باشد. خروجی‌ها ممکن است اطلاعات حساس پردازش‌ها را نشان دهند؛ پیش از اشتراک‌گذاری آن‌ها را پاک‌سازی کنید.
گام اول: تصویر کلی و وضعیت هر هسته را ببینید
uptime
top
vmstat 1 10
mpstat -P ALL 1 10
در top، کلید P پردازش‌ها را بر اساس CPU مرتب می‌کند و کلید 1 نمایش جداگانه پردازنده‌های منطقی را فعال می‌کند.
در vmstat این ستون‌ها نقطه شروع خوبی هستند:
r: تعداد کارهای آماده اجرا یا در حال اجرا؛b: تعداد کارهای مسدودشده در انتظار I/O؛usوsy: زمان CPU در فضای کاربر و هسته؛wa: زمان انتظار I/O؛st: زمان ربوده‌شده در محیط مجازی؛siوso: فعالیت ورود و خروج swap.
گزارش اول vmstat برای بسیاری از شاخص‌ها میانگین از زمان راه‌اندازی سیستم است؛ گزارش‌های بعدی بازه نمونه‌برداری را نشان می‌دهند.
اگر یک هسته کامل مشغول است اما میانگین کل پایین به نظر می‌رسد، مسیر تک‌ریسمانی یا محدودیت توزیع کار را بررسی کنید. اگر r در چند نمونه از ظرفیت پردازشی قابل استفاده بیشتر است، احتمال صف انتظار CPU وجود دارد؛ البته در محیط محدودشده باید سهمیه و پردازنده‌های مجاز را هم لحاظ کنید.
گام دوم: پردازش و ریسمان پرمصرف را پیدا کنید
pidstat -u -p ALL 1 10
پس از شناسایی PID، عدد نمونه زیر را با PID واقعی جایگزین کنید:
PID=12345
pidstat -t -u -p "$PID" 1 10
top -H -p "$PID"
حالت ریسمانی کمک می‌کند مشخص شود مصرف بین چند ریسمان توزیع شده یا یک ریسمان عامل اصلی است.
دیدن نام php-fpm یا mysqld پایان عیب‌یابی نیست. اکنون باید مصرف را به درخواست، کوئری یا تابع مشخص مرتبط کنید.
گام سوم: بازه مصرف را با لاگ‌ها تطبیق دهید
زمان وقوع مشکل و منطقه زمانی را ثبت کنید؛ سپس همان بازه را در این منابع بررسی کنید:
- access log و error log وب‌سرور؛
- لاگ برنامه و traceهای APM؛
- آمار و لاگ کوئری‌های دیتابیس؛
- لاگ صف و کارهای زمان‌بندی‌شده؛
- تاریخچه استقرار و تغییر تنظیمات.
در PHP-FPM، تنظیم request_slowlog_timeout همراه با slowlog می‌تواند برای درخواست‌های عبورکرده از آستانه زمانی، backtrace ثبت کند. این خروجی محل توقف یا اجرای درخواست را نشان می‌دهد، اما به‌تنهایی اثبات نمی‌کند آن بخش CPU مصرف می‌کند.
فعال‌سازی لاگ تشخیصی باید با آستانه متناسب، دسترسی محدود و کنترل حجم انجام شود. صفحه وضعیت FPM یا جزئیات تشخیصی را عمومی نکنید.
گام چهارم: محدودیت CPU را بررسی کنید
در محیط‌های مبتنی بر cgroup v2، فایل‌های cpu.max و cpu.stat در cgroup مربوط به workload اطلاعات مهمی دارند:
cpu.max: سهمیه و دوره زمانی تخصیص CPU؛nr_throttled: تعداد دوره‌هایی که محدودسازی رخ داده است؛throttled_usec: زمان ثبت‌شده محدودسازی.
برای مثال، مقدار 200000 100000 در cpu.max سقف متوسطی معادل دو CPU در آن دوره تعیین می‌کند؛ این مقدار به معنی رزرو دو هسته اختصاصی نیست. محدودیت‌های والد و مجموعه پردازنده‌های مجاز نیز می‌توانند ظرفیت مؤثر را کاهش دهند.
شمارنده‌ها را در دو زمان مقایسه کنید. عدد تجمعی بزرگ، بدون دانستن تغییر آن در بازه مشکل، برای تشخیص کافی نیست. همچنین باید cgroup خود سرویس را بررسی کنید، نه صرفاً ریشه فایل‌سیستم cgroup.
اگر فقط به پنل هاست دسترسی داریم چه کنیم؟
در هاست اشتراکی، مشاهده همه پردازش‌های سرور معمولاً ممکن نیست. هدف شما جمع‌آوری شواهد مربوط به حساب خودتان است:
- در بخش مصرف منابع، نمودار CPU و محدودیت‌های نمایش‌داده‌شده را بررسی کنید. نام و امکانات این بخش به پنل و ابزارهای نصب‌شده بستگی دارد.
- زمان دقیق جهش مصرف و مدت آن را یادداشت کنید.
- access log، error log و تغییرات اخیر سایت را تطبیق دهید.
- اگر snapshot پردازش‌ها موجود است، آن را ذخیره کنید.
- از پشتیبانی، تعریف دقیق درصد CPU و نوع محدودیت اعمال‌شده را بخواهید.
نمونه درخواست فنی از پشتیبانی:
در بازه … با منطقه زمانی … افزایش زمان پاسخ و رسیدن CPU حساب به سقف مشاهده شده است. لطفاً سهمیه دقیق CPU، وقوع احتمالی محدودسازی، snapshot پردازش‌ها و وضعیت هم‌زمان حافظه و I/O حساب را بررسی کنید. همچنین مشخص کنید آیا در همین بازه میزبان اصلی نیز با اشباع منابع مواجه بوده است.
این اطلاعات بسیار مفیدتر از درخواست کلی «منابع را بیشتر کنید» است.
هنگام بحران، چه اقدام‌هایی اولویت دارند؟
ترتیب زیر کمک می‌کند بدون از بین بردن شواهد، سرویس را پایدار کنید:
- ثبت وضعیت کوتاه: نمودارها، پردازش‌های اصلی، زمان شروع و تغییرات اخیر را ثبت کنید.
- کاهش بار غیرضروری: کارهای پس‌زمینه غیرحیاتی را موقتاً متوقف یا هم‌زمانی آن‌ها را محدود کنید.
- مهار ورودی پرهزینه: برای مسیر مسئله‌ساز، محدودسازی کنترل‌شده یا غیرفعال‌سازی موقت قابلیت را بررسی کنید.
- بازگشت تغییر مشکوک: اگر مشکل پس از انتشار نسخه شروع شده، rollback آزموده‌شده را در نظر بگیرید.
- افزایش ظرفیت موقت: اگر شواهد کمبود ظرفیت را تأیید می‌کند و معماری اجازه می‌دهد، منابع را افزایش دهید.
- رفع ریشه‌ای و اعتبارسنجی: پس از عبور از بحران، علت را با شواهد و مقایسه قبل و بعد تأیید کنید.
ری‌استارت ممکن است موقتاً صف یا وضعیت معیوب را پاک کند، اما علت را اثبات یا برطرف نمی‌کند. از اجرای کورکورانه kill -9، تغییر گسترده تنظیمات و حذف داده‌های دیتابیس پرهیز کنید.
چه زمانی ارتقای سرور منطقی است؟
ارتقا زمانی توجیه فنی دارد که:
- بار واقعی و موردنیاز کسب‌وکار افزایش یافته باشد؛
- پردازش غیرعادی یا هزینه قابل‌حذف مهمی باقی نمانده باشد؛
- اشباع CPU یا محدودیت سهمیه در بازه‌های معنادار تکرار شود؛
- زمان پاسخ هدف با ظرفیت فعلی تأمین نشود؛
- آزمون بار نشان دهد افزایش منابع واقعاً توان پردازش را بالا می‌برد.
بیشتر شدن vCPU تضمین نمی‌کند عملکرد به همان نسبت افزایش یابد. مسیر تک‌ریسمانی، قفل‌های مشترک، دیتابیس اشباع یا محدودیت‌های میزبان ممکن است مانع مقیاس‌پذیری شوند. همچنین عنوان «VPS» به‌تنهایی به معنی هسته فیزیکی اختصاصی نیست؛ نوع تخصیص منابع باید در مشخصات سرویس روشن باشد.
چگونه مطمئن شویم مشکل حل شده است؟
کاهش نمودار CPU به‌تنهایی کافی نیست؛ ممکن است درخواست‌های کمتری پاسخ گرفته باشند. قبل و بعد از تغییر، در بار قابل مقایسه این شاخص‌ها را بسنجید:
- تعداد درخواست موفق در ثانیه؛
- تأخیر صدک ۹۵ و ۹۹؛
- نرخ خطا و timeout؛
- زمان CPU مصرف‌شده به‌ازای درخواست موفق؛
- طول صف و تعداد کارهای عقب‌افتاده؛
- نرخ برخورد کش؛
- تغییر شمارنده‌های محدودسازی CPU.
برای پیشگیری، این شاخص‌ها را همراه با زمان انتشار نسخه و اجرای کارهای زمان‌بندی‌شده روی داشبورد ثبت کنید. هشدار نیز بهتر است بر مصرف پایدار، اشباع و اثر آن بر سرویس متکی باشد، نه صرفاً یک جهش لحظه‌ای.
پرسش‌های متداول
چرا CPU بالا است ولی بازدید سایت زیاد نیست؟
ممکن است چند درخواست پرهزینه، کار پس‌زمینه، کوئری تکراری، حلقه معیوب یا پردازش غیرمجاز منابع را مصرف کنند. تعداد بازدید معیار مستقیمی برای هزینه پردازشی نیست.
آیا افزایش RAM مصرف CPU را کاهش می‌دهد؟
فقط در بعضی سناریوها؛ مثلاً وقتی کمبود حافظه باعث فشار بازیابی حافظه یا افت کارایی کش شده باشد. برای کدی که ذاتاً CPU-bound است، افزایش RAM درمان مستقیم نیست.
آیا خطای ۵۰۳ ثابت می‌کند CPU اشباع شده است؟
خیر. خطای ۵۰۳ می‌تواند از نبود worker آزاد، محدودیت سرویس، نگهداری یا مشکل upstream ناشی شود. باید آن را با لاگ و شاخص‌های منابع تطبیق داد.
آیا نصب افزونه کش همیشه مشکل را حل می‌کند؟
خیر. کش برای پاسخ‌ها و داده‌های قابل استفاده مجدد مفید است. عملیات شخصی‌سازی‌شده، برخی درخواست‌های نوشتن یا پردازش‌های پس‌زمینه ممکن است از کش صفحه سودی نبرند.
جمع‌بندی
برای رفع مصرف بالای CPU، ابتدا تعریف عدد نمایش‌داده‌شده و ظرفیت واقعی سرویس را مشخص کنید؛ سپس مصرف برنامه را از انتظار I/O، محدودسازی سهمیه و مشکلات محیط مجازی جدا کنید. بعد، مسیر را از پردازش پرمصرف تا درخواست، کوئری یا کد مسئول ادامه دهید.
بهترین راهکار، تغییری است که هزینه پردازش را کاهش دهد یا ظرفیت لازم را فراهم کند، بدون آنکه صحت پاسخ و پایداری سرویس قربانی شود.
برای ادامه یادگیری، راهنمای رایگان روش USE از Brendan Gregg را مطالعه کنید. این چارچوب کمک می‌کند عیب‌یابی را از حدس‌زدن درباره CPU به بررسی منظم مصرف، اشباع و خطاهای منابع تبدیل کنید.
دیدگاه‌ها (۰)
هنوز دیدگاهی ثبت نشده است. اولین نفر باشید!