CPU Steal چیست؟ چگونه Overselling و کیفیت واقعی VPS را بررسی کنیم؟

فرض کنید یک سرور مجازی با ۴ هسته CPU و ۸ گیگابایت RAM خریده‌اید. سایت یا برنامه شما نیز مصرف چندان بالایی ندارد، RAM پر نشده و CPU ظاهراً درگیر نیست؛ اما بعضی ساعت‌ها سایت ناگهان کند می‌شود، اجرای دستورات SSH تأخیر دارد و پردازش‌هایی که قبلاً سریع انجام می‌شدند زمان بیشتری می‌برند.

اولین حدس معمولاً مشکل کد، دیتابیس، شبکه یا کمبود منابع است.

اما در محیط‌های مجازی یک عامل کمتر شناخته‌شده نیز وجود دارد:

CPU Steal Time

CPU Steal مدت زمانی است که CPU مجازی VPS آماده اجرای پردازش بوده، اما Hypervisor نتوانسته CPU فیزیکی را در همان لحظه در اختیار آن قرار دهد؛ زیرا پردازنده میزبان در حال سرویس‌دهی به ماشین‌های مجازی دیگر بوده است. این تعریف با توضیح فنی ارائه‌شده برای محیط‌های VPS نیز همخوان است.

CPU Steal کم و مقطعی در زیرساخت مجازی الزاماً مشکل نیست. اما اگر مقدار آن برای مدت قابل‌توجهی بالا بماند و هم‌زمان افت Performance مشاهده شود، باید وضعیت Node میزبان و رقابت روی CPU بررسی شود.

این شاخص یکی از ابزارهایی است که کمک می‌کند تفاوت میان «سرور من CPU مصرف می‌کند» و «سرور من منتظر CPU فیزیکی است» را تشخیص دهید.

CPU Steal دقیقاً چیست؟

برای درک Steal Time باید ساختار VPS را بشناسیم.

فرض کنید یک سرور فیزیکی قدرتمند وجود دارد و با استفاده از Hypervisor چند ماشین مجازی روی آن ساخته شده است:

Physical Server
        ↓
    Hypervisor
   ↓    ↓    ↓
 VPS1  VPS2  VPS3

هر VPS تعدادی vCPU دریافت می‌کند.

اما vCPU الزاماً یک هسته فیزیکی کاملاً اختصاصی نیست. Hypervisor زمان پردازنده فیزیکی را میان ماشین‌های مجازی مدیریت می‌کند.

حالا فرض کنید VPS شما آماده اجرای یک Process است.

سیستم‌عامل می‌گوید:

«من برای اجرای این Process به CPU نیاز دارم.»

اما Hypervisor در آن لحظه CPU را در اختیار VM دیگری قرار داده است.

VPS شما مجبور می‌شود منتظر بماند.

زمان این انتظار در Linux می‌تواند به‌عنوان:

steal

یا:

st

نمایش داده شود.

به همین دلیل Steal Time در محیط مجازی می‌تواند اطلاعات مهمی درباره رقابت برای CPU میزبان ارائه دهد.

CPU Steal با CPU Usage چه تفاوتی دارد؟

این دو مفهوم کاملاً متفاوت‌اند.

CPU Usage نشان می‌دهد برنامه‌ها و Processهای داخل VPS چه مقدار از CPU در دسترس را مصرف کرده‌اند.

CPU Steal نشان می‌دهد VPS چه مقدار از زمانی که آماده استفاده از CPU بوده، منتظر Hypervisor مانده است.

فرض کنید وضعیت CPU چنین باشد:

CPU Usage: 25%
CPU Steal: 30%

ممکن است تصور کنید چون Application فقط ۲۵ درصد CPU مصرف می‌کند، سرور مشکلی ندارد.

اما Steal بالا نشان می‌دهد VM بخشی از زمان اجرای بالقوه خود را در انتظار Host گذرانده است.

بنابراین هنگام عیب‌یابی VPS فقط ستون CPU Usage را بررسی نکنید.

چگونه CPU Steal را ببینیم؟

یکی از ساده‌ترین روش‌ها استفاده از دستور:

top

است.

پس از اجرای آن معمولاً خطی مشابه زیر مشاهده می‌شود:

%Cpu(s):  8.1 us, 2.3 sy, 0.0 ni, 86.2 id, 0.4 wa, 0.0 hi, 0.0 si, 3.0 st

قسمت موردنظر:

st

است.

st مخفف Steal Time است.

در مثال بالا:

3.0 st

یعنی حدود ۳ درصد زمان CPU در آن نمونه به Steal اختصاص داشته است.

مشاهده Steal با vmstat

ابزار دیگری که می‌توان استفاده کرد:

vmstat 1

است.

عدد 1 باعث می‌شود اطلاعات تقریباً هر ثانیه به‌روزرسانی شوند.

خروجی شامل ستون‌هایی مانند:

us
sy
id
wa
st

خواهد بود.

ستون st همان Steal است.

مزیت vmstat این است که می‌توانید رفتار سرور را برای مدتی مشاهده کنید و متوجه شوید Steal فقط یک Spike کوتاه است یا دائماً بالا باقی می‌ماند.

برای مثال:

us sy id wa st
15  4 75  1  5
18  5 70  1  6
20  4 67  1  8
17  4 40  2 37

ردیف آخر نیازمند بررسی است، زیرا Steal ناگهان به ۳۷ درصد رسیده است.

اما از یک نمونه منفرد نمی‌توان درباره کیفیت کل VPS حکم داد.

چه مقدار CPU Steal طبیعی است؟

هیچ عدد جهانی وجود ندارد که برای همه Hypervisorها، Providerها و Workloadها مرز قطعی «خوب» و «بد» باشد.

Steal باید همراه با عملکرد واقعی Application تحلیل شود.

در محیط مجازی، مقدار اندک و کوتاه‌مدت می‌تواند طبیعی باشد. منابع پشتیبانی VPS نیز تأکید می‌کنند که وجود مقداری CPU Steal در محیط اشتراکی ذاتاً غیرعادی نیست.

اما برای تحلیل عملی می‌توان این نگاه را داشت:

این جدول قانون یا SLA استاندارد صنعت نیست؛ صرفاً چارچوبی برای عیب‌یابی است.

به‌خصوص برای Workloadهایی مانند Game Server، پردازش Real-Time، Node.js تک‌ریسمانی یا Worker حساس به Latency، حتی Steal پایین‌تر نیز ممکن است قابل احساس باشد.

بحث‌های کاربران VPS در ماه‌های اخیر نیز نشان می‌دهد Steal Time همچنان یکی از شاخص‌هایی است که کاربران برای بررسی کندی غیرمنتظره VPS دنبال می‌کنند؛ اما تجربه کاربران را نباید به‌تنهایی معیار فنی قطعی در نظر گرفت.

آیا CPU Steal بالا یعنی VPS Oversell شده؟

نه لزوماً.

این یکی از مهم‌ترین نکات مقاله است.

CPU Steal بالا می‌تواند نشانه CPU Contention روی Host باشد، اما از داخل VPS معمولاً نمی‌توانید فقط با مشاهده یک عدد ثابت کنید Provider عمداً Overselling انجام داده است.

ممکن است در آن لحظه:

• چند VM هم‌زمان پردازش سنگین داشته باشند؛
• عملیات Maintenance انجام شود؛
• Backup زیرساختی اجرا شود؛
• Host موقتاً تحت بار قرار گرفته باشد؛
• محدودیت یا Scheduler خاصی اعمال شده باشد.

بنابراین:

CPU Steal بالا = نشانه رقابت CPU

اما:

CPU Steal بالا ≠ اثبات قطعی Overselling

برای تشخیص بهتر باید رفتار را در چند ساعت و چند روز بررسی کنید.

Overselling چیست؟

Overselling در مفهوم عمومی میزبانی یعنی مجموع ظرفیتی که به مشتریان فروخته یا تخصیص داده می‌شود از ظرفیت قابل استفاده هم‌زمان زیرساخت بیشتر باشد، با این فرض که همه کاربران هم‌زمان سقف منابع خود را مصرف نمی‌کنند.

این ایده فقط در VPS وجود ندارد.

در هاست اشتراکی، فضای دیسک، Bandwidth و سایر منابع نیز می‌توانند با مدل‌های مشابه مدیریت شوند. حتی مستندات cPanel قابلیت Overselling برای Resellerها را توضیح می‌دهند؛ جایی که مجموع Quota حساب‌های ساخته‌شده می‌تواند از Allocation Reseller بیشتر باشد، تا زمانی که مصرف واقعی از حد تعیین‌شده عبور نکند.

در VPS موضوع حساس‌تر می‌شود؛ به‌خصوص درباره CPU.

فرض کنید Host دارای منابع مشخصی است اما ده‌ها VM روی آن اجرا می‌شوند.

اگر همه VMها در حالت Idle یا کم‌مصرف باشند، مشکلی وجود ندارد.

اما اگر تعداد زیادی هم‌زمان CPU بخواهند، رقابت ایجاد می‌شود.

این وضعیت می‌تواند Steal Time را افزایش دهد.

آیا Overselling همیشه بد است؟

نه.

این نکته معمولاً در مقالات تبلیغاتی نادیده گرفته می‌شود.

بسیاری از زیرساخت‌های Cloud و Hosting براساس این واقعیت طراحی شده‌اند که تمام مشتریان هم‌زمان ۱۰۰ درصد ظرفیت خود را استفاده نمی‌کنند.

مشکل زمانی ایجاد می‌شود که تراکم آن‌قدر بالا باشد که Performance کاربران به‌شکل محسوس و مداوم کاهش پیدا کند.

بنابراین مسئله اصلی:

Overselling کنترل‌شده یا کنترل‌نشده

است.

Provider حرفه‌ای ظرفیت Node را مانیتور می‌کند و در صورت افزایش Load، VMها را توزیع یا سخت‌افزار را ارتقا می‌دهد.

KVM جلوی Overselling را می‌گیرد؟

خیر.

این تصور که:

KVM = بدون Overselling

اشتباه است.

KVM امکان ایجاد Virtual Machine مستقل و مدیریت منابع آن را فراهم می‌کند، اما Provider همچنان نحوه تخصیص vCPU و ظرفیت Node را تعیین می‌کند.

CPU در بسیاری از VPSها ماهیت Shared دارد.

بنابراین ممکن است دو VPS هر دو KVM باشند اما Performance کاملاً متفاوتی داشته باشند.

در مقاله قبلی درباره KVM توضیح دادیم که نوع Virtualization فقط یکی از عوامل کیفیت VPS است.

عوامل مهم دیگر عبارت‌اند از:

• CPU Host
• تعداد VMها
• Storage
• Network
• RAM
• Hypervisor Configuration
• Resource Policy
• Monitoring

CPU Steal و Overselling چه ارتباطی دارند؟

فرض کنید ۲۰ VPS روی یک Host وجود دارند.

در ساعات عادی فقط ۵ VPS CPU زیادی مصرف می‌کنند.

همه چیز سریع است.

اما ساعت ۸ شب تعداد زیادی از VMها هم‌زمان پردازش سنگین شروع می‌کنند.

Hypervisor باید CPU فیزیکی را میان آن‌ها تقسیم کند.

در نتیجه VPS شما زمان بیشتری منتظر می‌ماند.

Steal افزایش پیدا می‌کند.

اگر این اتفاق هر روز در ساعات پرترافیک تکرار شود، احتمال وجود CPU Contention جدی‌تر می‌شود.

به همین دلیل یک تست پنج‌دقیقه‌ای بلافاصله بعد از خرید VPS کافی نیست.

VPS را چه زمانی تست کنیم؟

حداقل در چند بازه مختلف:

• صبح
• ظهر
• عصر
• ساعات پرترافیک شب
• روز کاری
• تعطیلات

همچنین تست را چند روز تکرار کنید.

اگر VPS همیشه سریع است اما یک بار Steal بالا مشاهده شده، نتیجه‌گیری عجولانه نکنید.

اما اگر هر شب:

st = 20% - 40%

می‌شود و هم‌زمان سایت کند می‌شود، اطلاعات مفیدی برای ارسال به پشتیبانی دارید.

CPU Steal تنها عامل کندی VPS نیست

این نکته بسیار مهم است.

ممکن است:

st = 0

باشد اما VPS همچنان بسیار کند عمل کند.

چرا؟

چون Bottleneck می‌تواند جای دیگری باشد.

مهم‌ترین موارد عبارت‌اند از:

• Disk I/O
• I/O Wait
• RAM
• Swap
• Database
• Network
• Application
• DNS
• PHP Worker
• MySQL Query
• External API

یک تجربه تازه منتشرشده از کاربری با VPS نیز دقیقاً چنین حالتی را گزارش کرده است: CPU Steal صفر بوده اما I/O Wait و Latency دیسک بالا عامل اصلی افت Performance بوده است. این تجربه موردی است، اما مثال خوبی برای نشان‌دادن خطر تمرکز روی یک Metric محسوب می‌شود.

I/O Wait چیست؟

در خروجی top علاوه بر st مقدار دیگری با نام:

wa

وجود دارد.

wa یا I/O Wait نشان می‌دهد CPU چه مقدار زمان منتظر تکمیل عملیات I/O بوده است.

برای مثال اگر Disk بسیار کند باشد، Process درخواست خواندن اطلاعات می‌دهد اما باید منتظر Storage بماند.

در چنین شرایطی ممکن است CPU Idle به نظر برسد ولی Application کند باشد.

اگر wa دائماً بالا است، باید Storage را بررسی کنید.

چگونه Disk VPS را بررسی کنیم؟

برای بررسی اولیه فضای دیسک:

df -h

برای مشاهده I/O می‌توانید از:

iostat

استفاده کنید.

در بعضی Distributionها ابتدا باید بسته sysstat نصب شود.

Ubuntu/Debian:

apt install sysstat

سپس:

iostat -xz 1

پارامترهایی مانند:

await
%util
r/s
w/s

می‌توانند برای تحلیل Storage مفید باشند.

اما تفسیر اعداد باید براساس نوع Disk و Workload انجام شود.

RAM را چگونه بررسی کنیم؟

دستور ساده:

free -h

خروجی‌ای مشابه زیر نمایش می‌دهد:

total
used
free
shared
buff/cache
available

در Linux فقط ستون free را معیار قرار ندهید.

Linux از RAM آزاد برای Cache استفاده می‌کند.

ستون مهم‌تر برای نگاه اولیه:

available

است.

همچنین Swap را بررسی کنید.

اگر سرور دائماً Swap سنگین دارد، احتمال کمبود RAM وجود دارد.

Load Average چیست؟

دستور:

uptime

یا top سه عدد Load Average نمایش می‌دهد.

مثلاً:

load average: 0.72, 0.84, 0.90

این اعداد میانگین Load در حدود:

• ۱ دقیقه
• ۵ دقیقه
• ۱۵ دقیقه

را نشان می‌دهند.

Load را باید نسبت به تعداد CPUها و نوع Workload تحلیل کرد.

Load بالا به‌تنهایی نمی‌گوید CPU مشکل دارد؛ Processهای منتظر I/O نیز می‌توانند در Load نقش داشته باشند.

چرا VPS با CPU پایین کند است؟

این یکی از سؤالات مهم کاربران است.

فرض کنید:

CPU Usage = 20%

اما سایت کند است.

دلایل احتمالی:

CPU Steal

VM منتظر CPU Host است.

I/O Wait

CPU منتظر Disk است.

Database Lock

MySQL منتظر Query یا Lock است.

PHP Worker

تمام Workerها مشغول هستند.

Network Latency

ارتباط با کاربر یا API خارجی کند است.

Swap

RAM کم است و سیستم از Disk استفاده می‌کند.

Single Thread Bottleneck

یک Process فقط یک Core را ۱۰۰ درصد مصرف کرده اما میانگین کل CPU پایین دیده می‌شود.

بنابراین Monitoring باید چندبعدی باشد.

تست CPU VPS با sysbench

برای Benchmark اولیه می‌توان از sysbench استفاده کرد.

روی Ubuntu/Debian:

apt update
apt install sysbench

سپس:

sysbench cpu --cpu-max-prime=20000 run

نتیجه شامل تعداد Eventها و مدت اجرای تست است.

اما نکته مهم:

Benchmark یک‌بار اجراشده معیار قطعی کیفیت VPS نیست.

بهتر است تست را در زمان‌های مختلف تکرار کنید.

هدف اصلی مقایسه Consistency است.

اگر نتیجه صبح و شب اختلاف بسیار زیادی دارد، باید دلیل آن بررسی شود.

تست هم‌زمان CPU Steal

یک Terminal باز کنید:

vmstat 1

در Terminal دیگر Benchmark را اجرا کنید:

sysbench cpu --threads=2 --cpu-max-prime=20000 run

حالا ستون:

st

را مشاهده کنید.

این روش به شما نشان می‌دهد VPS هنگام Load چه رفتاری دارد.

اما مراقب باشید Benchmark سنگین را روی Production Server در ساعات کاری اجرا نکنید.

تست شبکه VPS

برای بررسی اولیه Latency:

ping

مثلاً به یک مقصد معتبر.

برای بررسی Route:

traceroute

یا:

mtr

مفید است.

سرعت پایین سایت همیشه مشکل CPU نیست.

ممکن است Route بین کاربر و دیتاسنتر کیفیت مناسبی نداشته باشد.

این مسئله مخصوصاً هنگام انتخاب بین VPS ایران و خارج اهمیت دارد.

تست NVMe و Storage

یکی از اشتباهات رایج این است که فقط عبارت:

NVMe

را روی صفحه فروش ببینیم و تصور کنیم همه NVMeها Performance یکسانی دارند.

اما Storage ممکن است میان تعداد زیادی VM مشترک باشد.

علاوه بر سخت‌افزار، موارد زیر اثر دارند:

• RAID
• Storage Controller
• Cache
• Filesystem
• Node Load
• IOPS Limit
• Hypervisor

بنابراین Benchmark Storage نیز باید با احتیاط انجام شود.

ابزارهایی مانند fio برای تست حرفه‌ای‌تر استفاده می‌شوند، اما اجرای تست‌های سنگین Disk ممکن است روی Node و VPSهای دیگر اثر بگذارد و برخی Providerها آن را محدود کنند.

پیش از اجرای Benchmark سنگین، قوانین سرویس را بررسی کنید.

VPS خوب چه مشخصاتی دارد؟

عدد RAM و CPU تنها بخشی از داستان است.

یک VPS خوب باید در عمل:

• Performance پایدار داشته باشد؛
• CPU Steal غیرعادی و دائمی نداشته باشد؛
• Storage پایدار داشته باشد؛
• Packet Loss نداشته باشد؛
• Network Route مناسبی داشته باشد؛
• Downtime غیرعادی نداشته باشد؛
• امکان Monitoring داشته باشد؛
• Backup مشخصی داشته باشد؛
• امکان Upgrade داشته باشد؛
• Provider پاسخ‌گو داشته باشد.

برای Production، ثبات Performance معمولاً از Benchmark بسیار بالا در یک لحظه مهم‌تر است.

چرا ثبات مهم‌تر از Benchmark است؟

فرض کنید VPS A در Benchmark:

1000 requests/s

ثبت می‌کند.

VPS B:

850 requests/s

اما VPS A شب‌ها به:

350 requests/s

افت می‌کند.

درحالی‌که VPS B همیشه بین:

800 - 850 requests/s

باقی می‌ماند.

برای یک فروشگاه اینترنتی، VPS B می‌تواند انتخاب بهتری باشد.

کاربر به Benchmark شما اهمیت نمی‌دهد.

او انتظار دارد سایت هر ساعت روز سریع باشد.

چگونه VPS را ۲۴ ساعت مانیتور کنیم؟

ابزارهای مختلفی وجود دارند.

برای Monitoring ساده می‌توانید از:

• Netdata
• Grafana
• Prometheus
• Uptime Kuma

استفاده کنید.

برای بررسی سریع نیز ابزارهای داخلی Linux کافی هستند:

top
htop
vmstat
iostat
free
df
ss

هدف این است که هنگام بروز کندی، Historical Data داشته باشید.

بدون داده، عیب‌یابی تبدیل به حدس می‌شود.

هنگام CPU Steal بالا چه کار کنیم؟

اول زمان و مقدار آن را ثبت کنید.

برای مثال:

21:00 → st 4%
21:15 → st 18%
21:30 → st 32%
22:00 → st 27%

سپس بررسی کنید:

• CPU Usage خود VPS
• Load
• I/O Wait
• RAM
• Swap
• Disk
• Network

اگر فقط Steal بالا است و سایر منابع طبیعی هستند، اطلاعات را برای Provider ارسال کنید.

Provider ممکن است:

• Node را بررسی کند؛
• VMهای پرمصرف را مدیریت کند؛
• VPS شما را Migration کند؛
• محدودیت CPU را توضیح دهد؛
• پلن مناسب‌تری پیشنهاد کند.

آیا Reboot مشکل CPU Steal را حل می‌کند؟

معمولاً علت اصلی Steal بیرون از Guest OS است.

Reboot ممکن است بعضی مشکلات داخلی VPS را برطرف کند، اما اگر مشکل رقابت CPU روی Host باشد، Restart کردن VM الزاماً مشکل را حل نمی‌کند.

به همین دلیل قبل از Reboot کورکورانه، Metricها را ثبت کنید.

آیا ارتقای VPS مشکل را حل می‌کند؟

نه همیشه.

اگر RAM کم است، ارتقای RAM منطقی است.

اگر Application واقعاً CPU بیشتری نیاز دارد، ارتقای vCPU می‌تواند کمک کند.

اما اگر Node دچار Contention شدید باشد، خرید Core بیشتر روی همان زیرساخت الزاماً مشکل را برطرف نمی‌کند.

ابتدا Bottleneck را مشخص کنید.

Diagnose → Optimize → Upgrade

ترتیب منطقی همین است.

چک‌لیست تست VPS بعد از خرید

بعد از تحویل VPS این موارد را بررسی کنید:

مشخصات

lscpu

free -h

lsblk

Virtualization

systemd-detect-virt

فضای دیسک

df -h

CPU Steal

top

و:

vmstat 1

Disk I/O

iostat -xz 1

Load

uptime

Network

ping

و در صورت نیاز:

mtr

این تست‌ها را فقط یک بار انجام ندهید.

در ساعات مختلف تکرار کنید.

چک‌لیست قبل از خرید VPS

پیش از سفارش از Provider درباره موارد زیر اطلاعات بگیرید:

• نوع Virtualization
• مدل CPU
• تعداد vCPU
• RAM
• نوع Storage
• NVMe/SSD
• Port Speed
• Traffic
• IPv4
• IPv6
• Backup
• Snapshot
• Upgrade
• Reinstall
• Console
• Location
• SLA
• CPU Fair Usage Policy

مخصوصاً CPU Fair Usage Policy را مطالعه کنید.

عبارت «۴ vCPU» به‌تنهایی نمی‌گوید برای چه مدت می‌توانید چهار vCPU را تحت Load کامل قرار دهید.

CPU Dedicated و Shared چه تفاوتی دارند؟

در Shared CPU VPS، زمان پردازنده بین چند VM تقسیم می‌شود.

این مدل برای:

• وب‌سایت
• Development
• ربات
• پروژه سبک
• سرویس با Burst کوتاه

اقتصادی است.

اما برای:

• Encoding
• Game Server حساس
• Build Server
• پردازش مداوم
• Real-Time Application

ممکن است Dedicated vCPU یا زیرساختی با سیاست CPU تضمین‌شده مناسب‌تر باشد.

حتماً تعریف Provider از عبارت «Dedicated CPU» را بخوانید؛ اصطلاحات بازاریابی شرکت‌ها الزاماً یکسان نیستند.

CPU Steal برای WordPress مهم است؟

بله، مخصوصاً برای سایت پرترافیک.

WordPress و WooCommerce می‌توانند عملیات PHP و Database زیادی داشته باشند.

اگر CPU Host در ساعات شلوغ دچار Contention شود، ممکن است:

• TTFB افزایش یابد؛
• wp-admin کند شود؛
• Checkout دیر پاسخ دهد؛
• Cron Job طول بکشد؛
• Import کند شود.

اما قبل از مقصر دانستن VPS باید Pluginها، Queryها، Cache و PHP Worker نیز بررسی شوند.

CPU Steal برای WooCommerce

WooCommerce حساس‌تر است؛ زیرا بسیاری از صفحات Dynamic هستند.

Checkout، Cart و My Account را نمی‌توان مانند صفحات ثابت به‌طور کامل Page Cache کرد.

بنابراین ثبات CPU برای فروشگاه اهمیت بیشتری دارد.

در زمان کمپین فروش، VPS باید بتواند افزایش هم‌زمان PHP و Database Request را مدیریت کند.

اگر Steal نیز هم‌زمان بالا باشد، Performance می‌تواند غیرقابل پیش‌بینی شود.

CPU Steal برای Node.js و ربات

برخی برنامه‌های Node.js بخش مهمی از پردازش را روی Event Loop انجام می‌دهند.

در Workloadهای حساس به Latency، وقفه CPU می‌تواند محسوس باشد.

ربات‌های Real-Time، Game Server و WebSocket Application نیز ممکن است نسبت به نوسان CPU حساس باشند.

در یک بحث تازه در جامعه VPS در مه ۲۰۲۶، کاربری که یک Game Server مبتنی بر Node.js اجرا می‌کرد مشخصاً ثبات Steal Time را به‌دلیل حساسیت Loop اصلی برنامه مطرح کرده بود. این یک تجربه کاربری است، نه Benchmark عمومی، اما نشان می‌دهد چرا Steal برای بعضی Workloadها مهم‌تر از سایت معمولی است.

آیا VPS ارزان الزاماً Oversell شده است؟

خیر.

قیمت پایین به‌تنهایی چیزی را ثابت نمی‌کند.

Provider ممکن است:

• سخت‌افزار را عمده خریداری کرده باشد؛
• دیتاسنتر ارزان‌تری داشته باشد؛
• Automation بالایی داشته باشد؛
• Support محدودتری ارائه کند؛
• Margin کمتری داشته باشد.

در مقابل، VPS گران نیز الزاماً Performance عالی ندارد.

به همین دلیل تست و Monitoring از قضاوت براساس قیمت بهتر است.

جمع‌بندی؛ چطور کیفیت واقعی VPS را بفهمیم؟

کیفیت VPS را نمی‌توان فقط از روی جدول پلن تشخیص داد.

۴ vCPU، ۸GB RAM و ۱۰۰GB NVMe اطلاعات مهمی هستند، اما به شما نمی‌گویند سرور در ساعت ۱۰ شب چگونه عمل خواهد کرد.

برای ارزیابی واقعی باید چند شاخص را کنار هم قرار دهید:

CPU Usage + CPU Steal + Load + I/O Wait + RAM + Disk + Network

CPU Steal نشان می‌دهد VM چه مقدار زمان منتظر CPU فیزیکی بوده است و به همین دلیل Metric ارزشمندی برای محیط‌های مجازی است.

اما Steal بالا را به‌تنهایی معادل Overselling قطعی ندانید.

اگر Steal برای مدت طولانی بالا است، هم‌زمان Performance افت می‌کند و این الگو در ساعات مختلف تکرار می‌شود، موضوع را مستند کنید و با Provider در میان بگذارید.

و هنگام خرید VPS، فقط سؤال نکنید:

چند Core دارد؟

سؤال بهتر این است:

این Coreها در عمل چقدر پایدار هستند؟

سؤالات متداول

CPU Steal چیست؟

CPU Steal مدت زمانی است که vCPU ماشین مجازی آماده اجرا بوده اما به‌دلیل زمان‌بندی Hypervisor منتظر دسترسی به CPU فیزیکی مانده است.

st در دستور top چیست؟

st مخفف Steal Time است. در VPS می‌تواند نشان دهد چه درصدی از زمان CPU به انتظار ناشی از Hypervisor اختصاص یافته است.

آیا CPU Steal صفر بهترین حالت است؟

Steal نزدیک صفر مطلوب است، اما مقدار اندک و مقطعی در محیط مجازی لزوماً مشکل محسوب نمی‌شود. باید روند و Performance واقعی برنامه بررسی شود.

آیا Steal بالا یعنی VPS Oversell شده است؟

نه به‌طور قطعی. Steal بالا نشان‌دهنده CPU Contention است، اما برای اثبات Overselling باید رفتار Node و سیاست تخصیص Provider نیز بررسی شود.

چگونه CPU Steal را بررسی کنیم؟

ساده‌ترین روش اجرای top و مشاهده مقدار st است. vmstat 1 نیز امکان مشاهده Steal در طول زمان را فراهم می‌کند.

چرا VPS با CPU Usage پایین کند است؟

ممکن است مشکل از CPU Steal، I/O Wait، Storage، Swap، Database، Network یا محدودیت یک Process تک‌ریسمانی باشد.

I/O Wait چیست؟

زمانی است که CPU منتظر تکمیل عملیات ورودی/خروجی مانند خواندن یا نوشتن روی Storage می‌ماند. در top معمولاً با wa نمایش داده می‌شود.

آیا KVM مانع Overselling می‌شود؟

خیر. KVM فناوری مجازی‌سازی است؛ سیاست تخصیص CPU و تعداد VMهای هر Node توسط Provider تعیین می‌شود.

آیا با افزایش vCPU مشکل Steal حل می‌شود؟

الزاماً خیر. اگر مشکل از Contention روی Host باشد، افزایش vCPU روی همان Node ممکن است مشکل اصلی را برطرف نکند.

بهترین روش تست VPS چیست؟

به‌جای یک Benchmark، CPU، Steal، RAM، I/O و Network را در چند بازه زمانی و تحت Workload واقعی مانیتور کنید.