CPU هاست؛ تشخیص اشباع، Throttling و ظرفیت واقعی سایت

پنل هاست می‌گوید CPU سایت شما «۹۰٪» شده است. پشتیبانی پیشنهاد می‌کند پلن را ارتقا دهید؛ افزونه بهینه‌سازی پیشنهاد می‌کند کش را روشن کنید؛ توسعه‌دهنده هم می‌گوید مشکل دیتابیس است. هیچ‌کدام از این جمله‌ها به‌تنهایی تشخیص نیستند. درصد CPU بدون دانستن مخرج، بازه زمانی، سهم یا سقف پردازنده، وضعیت Throttling، صف درخواست و مسیر کند، حتی می‌تواند شما را به خریدی ببرد که هیچ تغییری در سرعت ایجاد نمی‌کند.

این راهنما کمک می‌کند بفهمید CPU هاست واقعاً گلوگاه است یا فقط یک نشانه؛ قرارداد منابع پلن را به اعداد قابل‌آزمون تبدیل کنید؛ مصرف CPU را کنار Latency، Throughput، Error و Saturation بخوانید؛ درخواست کند وردپرس را پروفایل کنید؛ آزمون بار امن بسازید و فقط وقتی شواهد کافی دارید میان بهینه‌سازی، افزایش ظرفیت عمودی یا مقیاس‌پذیری افقی تصمیم بگیرید.

CPU هاست چیست و دقیقاً چه چیزی را می‌خرید؟

پردازنده دستورهای برنامه را اجرا می‌کند، اما عبارت «۲ CPU» یا «۴ Core» در صفحه فروش هاست قرارداد کاملی نیست. بسته به معماری، ممکن است درباره هسته فیزیکی، Thread سخت‌افزاری، vCPU ماشین مجازی، سهم نسبی یک Container یا سقف زمانی پردازنده در یک بازه صحبت کنیم. این واحدها قدرت یکسان و رفتار یکسان ندارند.

در مستندات رسمی Linux cgroup v2، فایل cpu.max سقف پهنای‌باند پردازنده را به‌صورت Quota و Period بیان می‌کند، cpu.weight وزن رقابت است و cpu.stat زمان مصرف، دفعات و مدت Throttling را گزارش می‌کند. بنابراین عدد CPU بدون Limit و Throttling ناقص است. مستندات رسمی Linux cgroup v2

چرا چهار هسته لزوماً چهار برابر سریع‌تر نیست؟

بخشی از کار باید به‌ترتیب اجرا شود، بخشی منتظر دیتابیس یا شبکه می‌ماند و بعضی مسیرها روی یک Lock یا یک Worker گیر می‌کنند. تنها بخش موازی‌پذیر می‌تواند از هسته‌های بیشتر استفاده کند. افزون بر آن، سربار هماهنگی، Context switch، رقابت بر سر Cache و محدودیت I/O وجود دارد. پس افزایش هسته ممکن است Throughput درخواست‌های مستقل را بالا ببرد، اما زمان یک درخواست تک‌ریسمانی را تقریباً ثابت نگه دارد.

پیش از ارتقا بپرسید:

• هدف کاهش زمان یک درخواست است یا پاسخ‌گویی هم‌زمان به درخواست‌های بیشتر؟
• برنامه واقعاً چند Worker فعال دارد و چند کار را موازی می‌کند؟
• یک هسته اشباع است یا همه سهم مجاز CPU؟
• بیشتر Wall time در اجرای CPU می‌گذرد یا انتظار دیتابیس، Disk و API؟
• سرعت هر vCPU پلن جدید بهتر است یا فقط تعداد آن بیشتر می‌شود؟

مسیر یک درخواست را پیش از مقصرکردن CPU ببینید

درخواست کاربر معمولاً از DNS، CDN یا WAF، شبکه و TLS، وب‌سرور، صف PHP-FPM، کد وردپرس، Object Cache، دیتابیس و سرویس‌های بیرونی عبور می‌کند. کندی هر مرحله می‌تواند در مرورگر به شکل «انتظار برای پاسخ سرور» دیده شود. CPU فقط یکی از این مرحله‌هاست.

Browser → DNS/CDN/WAF → Web server → PHP worker → WordPress
                                      ↘ Object cache
                                      ↘ Database
                                      ↘ Payment / SMS / Search / Other API

CPU time مدت زمانی است که پردازنده واقعاً برای یک Process کار کرده؛ Wall time زمان سپری‌شده از آغاز تا پایان است. اگر یک درخواست ۲ ثانیه طول بکشد ولی تنها ۸۰ میلی‌ثانیه CPU time مصرف کند، افزودن هسته احتمالاً درمان اصلی نیست. باید ۱٫۹۲ ثانیه انتظار را در Query، Disk، Lock، DNS یا API بیرونی پیدا کرد.

چهار متغیر ظرفیت: تقاضا، هزینه خدمت، هم‌زمانی و منابع

برای تحلیل CPU هاست چهار جزء را جدا کنید:

1. تقاضا: چند درخواست یا Job در ثانیه وارد می‌شود و ترکیب آن‌ها چیست؟
2. هزینه خدمت: هر نوع درخواست چقدر CPU time، Query و I/O مصرف می‌کند؟
3. هم‌زمانی: چند درخواست هم‌زمان در حال اجرا یا انتظار هستند؟
4. ظرفیت: چند CPU time، Worker، Connection و IOPS واقعاً قابل‌استفاده است؟

تغییر هر جزء نتیجه را عوض می‌کند. یک بات می‌تواند تقاضا را بالا ببرد؛ افزونه بد هزینه هر درخواست را زیاد کند؛ API کند هم‌زمانی را بالا نگه دارد؛ و Quota پایین ظرفیت را محدود کند. نمودار CPU به‌تنهایی نمی‌گوید کدام رخ داده است.

ماتریس طلایی عیب‌یابی CPU هاست

درصد CPU را با مخرج و بازه زمانی بخوانید

عدد «۱۰۰٪» می‌تواند معنای یک هسته کامل، کل چهار هسته، سقف یک LVE یا Quota یک Container را داشته باشد. میانگین پنج‌دقیقه‌ای نیز Spike ده‌ثانیه‌ای Checkout را صاف می‌کند. برای هر نمودار این قرارداد را ثبت کنید:

• منبع Metric و Scope: Host، VM، Container، Account، Process یا PHP pool؛
• مخرج: یک Core، همه Coreها یا Limit تخصیصی؛
• واحد و بازه نمونه‌برداری؛
• Aggregation: average، max، p95 یا rate؛
• Timezone و هم‌بستگی با Release، Cron، کمپین و خطا؛
• رفتار Missing data و Reset پس از Restart.

برای طراحی داشبورد و Timeline رخدادها، راهنمای Observability و مانیتورینگ لحظه‌ای سایت را در کنار این مقاله اجرا کنید.

Utilization، Saturation و Error را از هم جدا کنید

Utilization می‌گوید چه بخشی از منبع مشغول بوده؛ Saturation می‌گوید چه مقدار کار به دلیل کمبود منبع منتظر مانده؛ Error نتیجه شکست است. در بسیاری از Incidentها، Saturation زودتر از Error و گاهی با CPU average ظاهراً عادی دیده می‌شود.

Quota، Weight، Burst و Throttling چه تفاوتی دارند؟

Weight می‌گوید هنگام رقابت، یک گروه نسبت به گروه دیگر چه اولویتی دارد. Quota سقف CPU time را در Period مشخص می‌کند. Burst اجازه می‌دهد در شرایط تعریف‌شده برای مدتی از ظرفیت ذخیره استفاده شود. Throttling یعنی Scheduler اجرای گروه را تا Period بعد محدود کرده است. بنابراین ممکن است Host پردازنده آزاد داشته باشد، اما Container به سقف قراردادی خودش خورده و منتظر بماند.

Kubernetes نیز CPU request را عمدتاً برای Scheduling و Weight رقابت به‌کار می‌برد و CPU limit را با Throttling اعمال می‌کند. یک CPU unit بسته به Node می‌تواند هسته فیزیکی یا مجازی باشد؛ پس نام «یک CPU» به تنهایی Benchmark نیست. مستندات رسمی مدیریت منابع Kubernetes

هاست اشتراکی و خطای ۵۰۸: همه‌چیز CPU نیست

در بسیاری از هاست‌های اشتراکی CloudLinux، حساب با LVE محدود می‌شود. محدودیت‌ها می‌توانند CPU speed، حافظه فیزیکی، I/O، IOPS، تعداد Process و Entry Process باشند. رسیدن به CPU یا I/O معمولاً سایت را کند می‌کند؛ رسیدن به حافظه یا تعداد Process ممکن است خطای ۵۰۰/۵۰۳ بسازد؛ و ۵۰۸ به‌طور مشخص می‌تواند از ردشدن ورود جدید به دلیل سقف Entry Process ایجاد شود.

پس جمله «۵۰۸ یعنی CPU تمام شده» دقیق نیست. EP ممکن است به این دلیل پر شود که درخواست‌ها در API بیرونی، Query کند یا Lock معطل‌اند. افزایش CPU شاید کمک کند یا نکند. نمودار Fault هر محدودیت، زمان خطا، Endpoint و مدت درخواست را کنار هم بگذارید. جزئیات رفتار LVE در مستندات رسمی CloudLinux Limits آمده است.

VPS اختصاصی مطلق نیست

VPS کنترل و جداسازی بیشتری از هاست اشتراکی می‌دهد، اما هر vCPU الزاماً هسته فیزیکی اختصاصی یا عملکرد تضمین‌شده نیست. Host می‌تواند Overcommit داشته باشد و Workloadهای همسایه بر زمان‌بندی، Cache یا I/O اثر بگذارند. معیارهای زیر را در قرارداد یا آزمایش بخواهید:

• نوع vCPU: shared، dedicated، reserved یا burstable؛
• مدل CPU، نسل، فرکانس و ثبات آن؛
• Steal/ready time و سیاست Oversubscription؛
• Disk class، IOPS/throughput و Latency؛
• شبکه داخلی/بین‌المللی، Packet loss و سقف Bandwidth؛
• سیاست Migration، Maintenance و جبران SLA؛
• امکان Snapshot، Backup مستقل و خروج داده.

Dedicated، Container، Cloud و Serverless را چگونه مقایسه کنیم؟

امنیت و Performance به نام سرویس تضمین نمی‌شود. Dedicated با Patch بد یا بدون Failover می‌تواند ضعیف‌تر از Managed hosting خوب باشد. مقایسه را بر اساس SLO، کنترل، شواهد ظرفیت و هزینه کل مالکیت انجام دهید؛ برای بعد مالی، راهنمای مدیریت هزینه کلود و FinOps مکمل این تصمیم است.

CPU هاست و PHP-FPM: صف Worker را ببینید

در WordPress، PHP-FPM معمولاً چند Process برای اجرای درخواست‌های Dynamic دارد. pm.max_children سقف Workerهای هم‌زمان Pool است. اگر همه Workerها مشغول باشند، درخواست‌های جدید در Listen queue منتظر می‌مانند؛ حتی اگر CPU کل سرور ۱۰۰٪ نباشد. افزایش بی‌حساب Worker نیز می‌تواند RAM را تمام یا دیتابیس را اشباع کند.

Status page رسمی PHP-FPM مواردی مانند Listen queue، Active/Idle process، Max active، max children reached و Slow request را گزارش می‌کند. این صفحه URL درخواست‌ها و اطلاعات منابع را آشکار می‌کند و باید فقط از IP داخلی یا مجاز در دسترس باشد. راهنمای رسمی PHP-FPM Status

قاعده تنظیم Worker

Worker را از روی «RAM تقسیم بر مصرف متوسط PHP» به‌تنهایی تنظیم نکنید. علاوه بر حافظه، ظرفیت CPU، Connection دیتابیس، طول Query، Endpoint mix و SLO مهم‌اند. تنظیم درست نتیجه آزمون بار با داده واقعی است: Worker را مرحله‌ای تغییر دهید و ببینید Throughput پیش از افت p95 و رشد Error تا کجا بالا می‌رود.

WordPress کجا CPU مصرف می‌کند؟

• Plugin یا Theme با Loop، Regex، Serialization یا پردازش تصویر سنگین؛
• Queryهای زیاد، N+۱، Join/Sort بدون Index مناسب یا Autoload حجیم؛
• WP-Cron و Jobهای Import، Backup، Email، Feed و ساخت Thumbnail؛
• درخواست‌های admin-ajax.php، REST و جست‌وجوی بدون Cache؛
• Cache miss و Stampede پس از Purge؛
• ربات‌ها، Brute force، Scraper و Hotlink؛
• تولید صفحه شخصی‌سازی‌شده، سبد خرید و Checkout؛
• کد قدیمی ناسازگار با نسخه PHP یا خطای Retry شونده.

پاک‌کردن Revisionهای قدیمی ممکن است اندازه بخشی از دیتابیس را کم کند، اما درمان عمومی CPU نیست. ابتدا ثابت کنید Query مربوط به Revision یا حجم جدول در مسیر کند حضور دارد. ویرایش مستقیم دیتابیس بدون Backup و Restore test نیز ریسک عملیاتی دارد.

Cache چه زمانی CPU را کم می‌کند و چه زمانی نه؟

Page cache می‌تواند اجرای WordPress/PHP را برای پاسخ‌های Cacheable حذف کند؛ Object cache رفت‌وبرگشت‌های تکراری به دیتابیس را کم می‌کند؛ OPcache از Compile دوباره PHP می‌کاهد؛ CDN فایل‌های Static و در بعضی معماری‌ها HTML را از Origin دور می‌کند. اما نتیجه به Cache eligibility، Hit ratio، TTL، Key، Invalidation و Stampede control وابسته است.

صفحات Login، سبد، Checkout، داشبورد، Preview، درخواست POST و محتوای شخصی‌سازی‌شده معمولاً سیاست متفاوتی می‌خواهند. اگر ۸۰٪ بار CPU از Job پس‌زمینه یا Checkout بدون Cache باشد، CDN تصاویر آن را حل نمی‌کند. معماری و خطاهای Invalidation را در راهنمای Cache وب‌سایت و مرز Origin/Edge را در راهنمای CDN برای سایت ایرانی بررسی کنید.

مستندات WordPress نیز Cache، Object cache، Offloading و CDN را از ابزارهای کاهش بار می‌داند، اما به تفاوت Hosting، Plugin، Theme، دیتابیس و ترافیک مخرب اشاره می‌کند؛ یعنی «نصب یک افزونه» جای اندازه‌گیری نیست. راهنمای رسمی بهینه‌سازی WordPress

از Trace به Profile برسید، نه از حدس به حذف افزونه

Trace درخواست را به Spanهای وب‌سرور، PHP، Query، Cache و API بیرونی می‌شکند. Profile می‌گوید CPU time در کدام Function یا Call stack مصرف شده است. ترتیب پیشنهادی:

1. Endpoint، زمان و شناسه درخواست کند را از Trace یا Access log پیدا کنید.
2. ببینید Wall time میان CPU، DB، Cache، Disk و Dependency چگونه تقسیم شده است.
3. اگر CPU سهم غالب است، Sampling profiler یا Flame graph بگیرید.
4. Function پرهزینه را به Plugin، Theme، Core یا کد سفارشی نگاشت کنید.
5. فرضیه بهینه‌سازی بسازید و قبل/بعد را با بار یکسان مقایسه کنید.

Profiler و Debug logging خودشان سربار دارند. در Production با Sampling محدود، دسترسی کنترل‌شده، حذف داده حساس و Window کوتاه کار کنید. افزونه را کورکورانه روی سایت زنده غیرفعال نکنید؛ در Staging یا Canary رفتار را مقایسه کنید.

Run queue، Load average و CPU pressure را درست تفسیر کنید

Run queue تعداد Taskهایی را نشان می‌دهد که آماده اجرا هستند ولی CPU نگرفته‌اند. Load average در Linux فقط «درصد CPU» نیست و می‌تواند Taskهای در انتظار غیرقابل‌وقفه، از جمله برخی انتظارهای I/O، را نیز دربر بگیرد. CPU Pressure Stall Information نشان می‌دهد Taskها چه مدت به دلیل دسترسی نداشتن به CPU معطل شده‌اند.

یک آستانه جهانی مانند «Load بالاتر از تعداد Core بد است» قانون قطعی نیست. معماری، مدت، Queue trend و SLO مهم‌اند. Alert را بر پیامد بسازید: مثلاً p95 بالا همراه CPU pressure یا Throttling، نه یک عدد جدا.

CPU بالا همیشه حادثه نیست

پردازنده‌ای که برای کار مفید استفاده می‌شود لزوماً مشکل نیست. اگر Throughput متناسب رشد کرده، p95 و Error در SLO هستند، صف پایدار است و Headroom رویدادهای پیش‌بینی‌شده کافی است، Utilization بالا می‌تواند بهره‌وری خوب باشد. حادثه زمانی است که تقاضای معتبر پاسخ نمی‌گیرد، Tail latency یا خطا بد می‌شود یا ظرفیت بازیابی از خرابی کافی نیست.

CPU پایین هم سلامت را ثابت نمی‌کند

میانگین CPU پایین می‌تواند یک Core اشباع، Quota پایین، Throttling دوره‌ای، صف PHP، Lock، I/O wait یا Spike کوتاه را پنهان کند. همچنین اگر Load balancer درخواست‌ها را پیش از رسیدن به سرور رد کند، CPU پایین می‌ماند اما کاربران خطا می‌بینند. نمودار را از Edge تا Application و Database پیوند دهید.

آزمون بار معتبر برای CPU هاست

آزمون بار فقط فرستادن تعداد زیادی درخواست به صفحه اصلی نیست. هدف یافتن بیشترین Throughput پایدار زیر SLO و مشاهده نقطه Knee است؛ جایی که افزایش اندک بار، p95، صف یا خطا را به‌سرعت بدتر می‌کند.

پیش‌نیازهای ایمنی

• مجوز مالک سامانه، میزبان و سرویس‌های وابسته را بگیرید؛
• ترجیحاً محیط Production-like با Dataset و Cache state نماینده بسازید؛
• برای Email، پیامک، پرداخت و وب‌هوک Sandbox یا Stub داشته باشید؛
• داده تست را از سفارش واقعی جدا و Cleanup/rollback تعریف کنید؛
• Stop condition برای Error، Saturation و اثر ناخواسته داشته باشید؛
• ژنراتور بار را جدا مانیتور کنید تا خودش گلوگاه نشود.

Traffic mix واقعی

این درصدها نسخه تجویزی نیستند؛ از Log واقعی خودتان بسازید. Test فقط Hit cache، توان مسیر Dynamic را پنهان می‌کند؛ Test فقط Checkout نیز ظرفیت عمومی سایت را نمایندگی نمی‌کند.

مدل بار و معیار قبولی

Ramping load برای یافتن Knee، Spike برای جهش کمپین، Soak برای Memory leak و Queue accumulation و Arrival-rate برای حفظ نرخ ورود مستقل از کندشدن پاسخ مفیدند. معیار Pass/Fail را پیشاپیش مشخص کنید؛ مثلاً:

هدف نمونه، نه استاندارد عمومی:
- p95 پاسخ Dynamic < 800 ms
- نرخ خطای غیرمنتظره < 0.5%
- PHP listen queue پس از پایان بار به صفر برگردد
- throttled time روند افزایشی پایدار نداشته باشد
- CPU headroom سناریوی خرابی یک Instance حفظ شود

مستندات k6، Threshold را معیار Pass/Fail قابل‌خودکارسازی معرفی می‌کند و Arrival-rate را از مدل Closed جدا می‌کند؛ در مدل Open، کندشدن سامانه نباید به‌طور مصنوعی نرخ ورود را پایین بیاورد. مستندات رسمی Threshold در k6

ظرفیت پایدار، Peak و Headroom

Capacity عددی نیست که یک‌بار اندازه بگیرید و فراموش کنید. آن را برای Version برنامه، Dataset، Cache state، Endpoint mix و زیرساخت مشخص ثبت کنید. خروجی آزمون باید شامل این موارد باشد:

• بیشترین request/s یا business transaction/s زیر SLO؛
• CPU time به ازای هر نوع درخواست؛
• p50/p95/p99 و Error در هر پله بار؛
• نقطه آغاز Queue و Throttling؛
• Headroom عادی، کمپین و خرابی یک Instance؛
• هزینه به ازای هزار درخواست یا سفارش موفق؛
• شرایط ابطال نتیجه: Release، Plugin، PHP یا Dataset جدید.

برای سرویس حساس، ظرفیت N+۱ را بسنجید: اگر یک Node یا AZ از دست رفت، آیا باقی ظرفیت هنوز SLO را نگه می‌دارد؟ متوسط ماهانه نمی‌تواند Peak پنج‌دقیقه‌ای فروش ویژه را پوشش دهد.

یک مثال: فروشگاهی که با ارتقای CPU درمان نشد

فرض کنید فروشگاهی در ساعت ۲۱، p95 برابر ۴ ثانیه، CPU متوسط ۶۵٪ و خطای ۵۰۸ دارد. خرید پلن دوبرابری وسوسه‌کننده است. بررسی دقیق‌تر نشان می‌دهد:

1. ۵۰۸ هم‌زمان با EP fault است، نه CPU fault؛
2. PHP listen queue رشد می‌کند اما CPU time هر Checkout فقط ۱۲۰ms است؛
3. یک API حمل‌ونقل ۲٫۸ ثانیه پاسخ می‌دهد و Worker را نگه می‌دارد؛
4. Retry سمت برنامه تعداد درخواست به API را سه برابر کرده است؛
5. پس از Timeout، Circuit breaker، Cache نرخ و Retry با Backoff، p95 به ۹۰۰ms و EP fault به صفر می‌رسد.

در این مثال CPU جدید ممکن بود اثر کوچکی داشته باشد، اما گلوگاه انتظار خارجی و تکثیر Retry بود. همین منطق درباره Query lock، Disk I/O و صف Worker نیز صدق می‌کند.

اول بهینه‌سازی، بعد Vertical یا Horizontal؟

«بهینه‌سازی قبل از ارتقا» هم قانون مطلق نیست. اگر کمپین فردا آغاز می‌شود و اشباع CPU ثابت شده، Scale-up موقت همراه Rollback می‌تواند اقدام ایمن باشد؛ سپس Hot path اصلاح شود. تصمیم باید زمان، ریسک و هزینه فرصت را هم ببیند.

CPU هاست چه اثری بر Core Web Vitals دارد؟

CPU اشباع یا Throttleشده در Origin می‌تواند تولید پاسخ Dynamic را دیر کند و بخشی از TTFB را افزایش دهد. اما TTFB علاوه بر Backend شامل Redirect، DNS، Connection و TLS است. LCP نیز به TTFB، کشف Resource، دانلود و Render وابسته است؛ INP عمدتاً پاسخ‌گویی صفحه در مرورگر و کار Main thread را می‌سنجد. بنابراین CPU هاست «مستقیماً» LCP یا INP را تعیین نمی‌کند.

Core Web Vitals فعلی LCP، INP و CLS هستند؛ FID جای خود را به INP داده است. داده میدانی را بر اساس Device و Page type ببینید و Server metric را با Browser RUM هم‌بسته کنید. راهنمای رسمی Google درباره Core Web Vitals و تعریف رسمی TTFB در web.dev این مرزبندی را توضیح می‌دهند. برای اجرای RUM نیز راهنمای Core Web Vitals و RUM را ببینید.

CPU بیشتر تضمین رتبه سئو یا درآمد نیست

سرعت و پایداری می‌توانند تجربه و Crawl را بهتر کنند، اما از خرید CPU نمی‌توان افزایش رتبه، Conversion یا درآمد را نتیجه گرفت. ممکن است Bottleneck اصلاً CPU نباشد، یا بهبود Backend در برابر JavaScript سنگین مرورگر ناچیز بماند. فرضیه تجاری را با آزمایش کنترل‌شده و Metric Outcome مانند نرخ تکمیل Checkout، خطای سفارش و درآمد به ازای Session بسنجید.

داشبورد حداقلی CPU و ظرفیت

برای تشخیص سریع، Markerهای Release و کمپین را روی نمودارها قرار دهید. فقط میانگین نگذارید؛ Tail percentile و Max کوتاه‌مدت را هم ببینید. Alertهای پایداری و Synthetic check را مطابق راهنمای مانیتورینگ آپتایم طراحی کنید.

Alert خوب برای CPU چه شکلی است؟

Alert تک‌شرطی «CPU بالای ۸۰٪» معمولاً Noise می‌سازد. Alert چندسیگناله به Outcome نزدیک‌تر است:

هشدار بررسی:
p95_dynamic > SLO
AND (cpu_pressure بالا OR throttled_time در حال رشد OR php_listen_queue > 0)
FOR 5 minutes

هشدار ظرفیت پیشگیرانه:
forecast_peak_load > tested_sustainable_capacity × safety_factor
AND campaign_or_growth_window نزدیک است

مقدار SLO و Safety factor را از کسب‌وکار و آزمون خودتان بگیرید، نه از نسخه عمومی. Alert باید Runbook، Owner، داشبورد و راه Rollback داشته باشد.

Runbook ۱: جهش ناگهانی CPU

1. اثر کاربر: Availability، p95، Error و سفارش موفق را بررسی کنید.
2. زمان را با Deploy، Cron، Campaign، Bot و Backup تطبیق دهید.
3. Process/Container و Endpoint مصرف‌کننده را تفکیک کنید.
4. Throttling، Queue، DB، Disk و Dependency را کنار CPU ببینید.
5. اقدام مهار کم‌ریسک: Rate limit بات، توقف Job غیرضروری، Rollback یا Scale موقت.
6. پس از ثبات، Trace/Profile و علت ریشه‌ای را ثبت کنید.

Runbook ۲: Throttling با CPU average پایین

1. Scope و مخرج نمودار را تأیید کنید.
2. Resolution را از پنج دقیقه به بازه کوتاه‌تر ببرید.
3. nr_throttled و throttled_usec را نسبت به Period بخوانید.
4. Burst، Limit و Weight را از Provider بگیرید.
5. Spikeهای کوتاه Endpoint یا Job را پیدا کنید.
6. با Limit اصلاح‌شده یا زمان‌بندی Job، آزمایش A/B زیرساختی انجام دهید.

Runbook ۳: CPU بعد از Cron یا Job پس‌زمینه

1. Job owner، Schedule، مدت، رکوردهای پردازش‌شده و Retry را ثبت کنید.
2. هم‌پوشانی Jobها و اجرای تکراری را حذف کنید.
3. Batch size، Concurrency و Backpressure را محدود کنید.
4. کار را از مسیر Web جدا و Queue کنید.
5. Backlog age و زمان تکمیل را SLO قرار دهید.
6. Idempotency و Dead-letter را پیش از Retry خودکار بسازید.

Runbook ۴: حمله ربات یا Scraper

1. IP، ASN، User-Agent، Route و الگوی نرخ را از Log استخراج کنید.
2. ربات جست‌وجوی معتبر را با DNS/روش رسمی Verify کنید؛ صرف User-Agent کافی نیست.
3. در CDN/WAF Rate limit مرحله‌ای و Challenge متناسب بگذارید.
4. Endpointهای پرهزینه مانند Search، Login و XML-RPC را محافظت کنید.
5. False positive کاربران ایران و اپراتورهای NAT را پایش کنید.
6. پس از مهار، Rule، expiry و Owner بازبینی را ثبت کنید.

Runbook ۵: آماده‌سازی فروش ویژه یا کمپین

1. Peak و Traffic mix را با Marketing توافق کنید.
2. نسخه Production-like را با Cache cold/warm و مسیر Checkout تست کنید.
3. ظرفیت پایدار و ظرفیت N+۱ را زیر SLO بسنجید.
4. Auto/Manual scale، Feature flag، Queue و Rate limit را تمرین کنید.
5. Deploy freeze، On-call، کانال ارتباط و Stop rule تعیین کنید.
6. پس از کمپین، هزینه/سفارش و Headroom مصرف‌شده را مرور کنید.

چک‌لیست خرید هاست برای سایت ایرانی

در ایران، CPU فقط بخشی از تجربه است. محل سرور، کیفیت مسیر اپراتورها، اختلال بین‌الملل، دسترسی به سرویس‌های خارجی، پرداخت و پشتیبانی نیز مهم‌اند. از فروشنده پاسخ قابل‌سنجش بخواهید:

ریسک تأمین‌کننده و خروج‌پذیری در ایران

وابستگی به پنل، License، CDN، Registry یا SaaS خارجی ممکن است با پرداخت، محدودیت منطقه‌ای یا تغییر سیاست Provider مختل شود. موجودی وابستگی‌ها، مالک حساب، روش تمدید قانونی، جایگزین و زمان Migration را ثبت کنید. Snapshot داخل همان Provider Backup مستقل نیست؛ نسخه بازیابی‌شدنی را در مکان و Credential جدا نگه دارید.

در ارزیابی TCO، نیروی عملیات، مانیتورینگ، مهاجرت، Downtime، Backup، امنیت و تمدید ارزی را کنار قیمت CPU بگذارید. ارزان‌ترین پلن ممکن است با یک Incident یا مهاجرت اضطراری گران‌تر شود.

RACI تصمیم ظرفیت

برنامه ۳۰ روزه تشخیص CPU هاست

1. هفته اول: قرارداد منابع، Scope نمودار، Endpointهای حیاتی، SLO و تقویم Release/Cron را مستند کنید.
2. هفته دوم: RPS، p95/p99، Error، CPU user/system، Throttling، Queue، DB/Disk/API و PHP-FPM status را هم‌زمان کنید.
3. هفته سوم: سه مسیر پرهزینه را Trace/Profile و CPU/request، Query و Cache hit را اندازه بگیرید.
4. هفته چهارم: یک اصلاح کم‌ریسک و یک آزمون بار Production-like اجرا؛ ظرفیت پایدار، Knee و Headroom را ثبت کنید.

برنامه ۹۰ روزه ظرفیت و عملکرد

هر بهینه‌سازی یک فرضیه و Kill criterion داشته باشد. اگر Cache hit، Query fix یا CPU upgrade نتیجه پیش‌بینی‌شده را زیر بار یکسان نداد، تغییر را بازگردانید و فرضیه بعدی را آزمایش کنید. راه‌حل‌های موقت را به ثبت و مدیریت بدهی فنی متصل کنید تا به تنظیم دائمیِ بدون Owner تبدیل نشوند.

چک‌لیست نهایی پیش از ارتقای CPU

• آیا مخرج، Scope و Resolution درصد CPU مشخص است؟
• آیا CPU saturation یا Throttling هم‌زمان با افت SLO رخ می‌دهد؟
• آیا Run queue، CPU pressure و PHP queue بررسی شده‌اند؟
• آیا CPU time از Wall time تفکیک شده است؟
• آیا Endpoint، Plugin، Query یا Job پرهزینه معلوم است؟
• آیا DB، Disk، RAM، Network و API بیرونی رد یا تأیید شده‌اند؟
• آیا Cache hit و مسیرهای غیرCache جدا سنجیده شده‌اند؟
• آیا آزمون بار Traffic mix، SLO و Stop rule دارد؟
• آیا پلن جدید با Benchmark کنترل‌شده و Rollback قابل‌آزمایش است؟
• آیا هزینه کل، عملیات، Backup، امنیت و خروج‌پذیری دیده شده‌اند؟

پرسش‌های متداول درباره CPU هاست

CPU هاست چند هسته باشد؟

عدد عمومی مناسبی وجود ندارد. تعداد لازم به نرخ و ترکیب درخواست، CPU time هر درخواست، تعداد Worker، Cache hit، SLO، Peak و Headroom وابسته است. ظرفیت را با آزمون بار نماینده بسنجید؛ «چهار هسته» بدون مدل CPU، Quota و نوع اشتراک برای تصمیم کافی نیست.

آیا مصرف ۱۰۰ درصد CPU همیشه بد است؟

خیر. Burst کوتاه با Latency و Error سالم ممکن است طبیعی باشد. مشکل وقتی است که مصرف بالا با Throttling، Queue، افت Throughput، بدشدن p95/p99 یا خطا همراه شود و Headroom کافی برای Peak یا خرابی باقی نماند.

آیا خطای ۵۰۸ یعنی CPU هاست تمام شده است؟

نه لزوماً. در CloudLinux، ۵۰۸ معمولاً می‌تواند از رسیدن Entry Process به سقف ناشی شود. علت پرشدن EP ممکن است CPU، I/O، Query، API کند یا هم‌زمانی زیاد باشد. Faultهای CPU، EP، Memory، NPROC و I/O را جدا بررسی کنید.

VPS همیشه از هاست اشتراکی سریع‌تر است؟

خیر. VPS کنترل بیشتری می‌دهد، اما vCPU و Disk ممکن است اشتراکی باشند و مدیریت ضعیف، Cache نامناسب یا پیکربندی بد نتیجه را بدتر کند. Managed hosting خوب برای برخی Workloadها از VPS بدون عملیات مناسب سریع‌تر و پایدارتر است. با SLO و Benchmark خودتان مقایسه کنید.

کش یا ارتقای CPU؛ کدام را اول انجام دهیم؟

اگر بار غالب Cacheable و Hit ratio پایین است، اصلاح Cache معمولاً اهرم خوبی است. اگر مسیر حیاتی غیرCache، CPU-bound و Throttleشده است، افزایش ظرفیت یا اصلاح Hot path مناسب‌تر است. ابتدا سهم هر مسیر و CPU/request را اندازه بگیرید؛ سپس کم‌ریسک‌ترین اقدام مؤثر را آزمایش کنید.

جمع‌بندی

CPU هاست را نه با شعار «مغز سرور» و نه با تعداد Core بخرید. مسئله واقعی ظرفیت است: تقاضا با چه ترکیبی وارد می‌شود، هر درخواست چقدر CPU و انتظار دارد، چند کار هم‌زمان‌اند، Quota و Worker چه سقفی می‌سازند و از چه نقطه‌ای SLO می‌شکند. زنجیره معتبر تشخیص این است: اثر کاربر ← Latency/Error ← Queue/Saturation ← CPU/Throttling ← Endpoint و Call stack.

اگر این زنجیره CPU را مقصر نشان داد، میان اصلاح کد، Cache، تنظیم Worker، Scale-up و Scale-out با آزمون و هزینه کل انتخاب کنید. اگر نشان نداد، پول CPU را خرج پوشاندن گلوگاه دیگری نکنید. بهترین پلن میزبانی پلنی نیست که بزرگ‌ترین عدد هسته را دارد؛ پلنی است که قرارداد روشن، Telemetry قابل‌اعتماد، ظرفیت آزموده‌شده، مسیر رشد و خروج امن دارد.