چرا سرور مجازی ارزان کند است؟ Steal Time، Noisy Neighbor و چطور با ابزارهای لینوکسی VPS باکیفیت را تشخیص دهیم
سرور مجازی ارزان در نگاه اول انتخابی منطقی برای یک وبسایت تازه، محیط آزمایشی یا سرویس کمترافیک است. مشکل زمانی آشکار میشود که همان VPS با وجود مصرف پایین دیسک و شبکه، پاسخگویی کندی دارد: ورود به SSH چند ثانیه طول میکشد، نصب یک بسته ساده متوقف میشود یا زمان پاسخ برنامه در ساعات خاصی افزایش پیدا میکند.
همه این موارد به معنی ضعیف بودن دائمی پردازنده نیست. در بسیاری از سرویسهای ارزان، چند ماشین مجازی روی یک میزبان فیزیکی مشترک قرار دارند و منابعی مانند CPU، حافظه و دیسک بین آنها تقسیم میشود. اگر همسایهها بار زیادی ایجاد کنند، عملکرد VPS شما نیز افت میکند. در لینوکس دو نشانه مهم برای این وضعیت وجود دارد: مقدار بالای CPU Steal Time و الگوی رفتاری معروف به Noisy Neighbor.
در این مقاله ابتدا این دو مفهوم را توضیح میدهیم، سپس با ابزارهای خود لینوکس و یک آزمون ساده، کیفیت واقعی سرور مجازی را بررسی میکنیم.
CPU Steal Time چیست؟
هایپروایزر (مانند KVM یا Xen) زمان پردازنده فیزیکی را میان ماشینهای مجازی تقسیم میکند. سیستمعامل مهمان تصور میکند یک یا چند هسته در اختیار دارد، اما در عمل باید برای دریافت زمان اجرا با ماشینهای دیگر رقابت کند.
در خروجی ابزارهایی مانند top یا mpstat، درصدی با نام st یا steal نمایش داده میشود. این مقدار زمانی را نشان میدهد که سیستمعامل شما آماده اجرای پردازش بوده، اما هایپروایزر پردازنده را به ماشین مجازی دیگری اختصاص داده است. بنابراین، Steal Time مستقیماً از داخل VPS قابل مشاهده است و به شما میگوید هسته مجازی همیشه بهموقع سرویس نمیگیرد.
مقدار نزدیک به صفر معمولاً نشانه وضعیت مناسب است. اعداد یک تا سه درصد ممکن است در بارهای مقطعی طبیعی باشد، اما مقدار پایدار بالاتر از پنج درصد باید بررسی شود. اگر st به ۱۰، ۲۰ یا حتی ۳۰ درصد برسد، بخشی از ظرفیت خریداریشده عملاً در اختیار همسایههاست.
Steal Time با مصرف CPU داخل برنامه شما فرق دارد. ممکن است us و sy پایین باشند، ولی st بالا بماند. در این حالت برنامه شما کاری برای انجام ندارد؛ مشکل، منتظر ماندن برای نوبت پردازنده است.
Noisy Neighbor چگونه VPS را کند میکند؟
Noisy Neighbor یا «همسایه پرسروصدا» به ماشین مجازی دیگری روی همان میزبان گفته میشود که منابع مشترک را بیش از حد مصرف میکند. این همسایه میتواند با کامپایل مداوم، پردازش رمزنگاری، اجرای پایگاهداده سنگین یا مصرف شدید دیسک، روی سرویس شما اثر بگذارد.
این اثر فقط به CPU محدود نیست. اگر ذخیرهساز میزبان بین چند مشتری مشترک باشد، عملیات خواندن و نوشتن زیاد یک ماشین باعث افزایش زمان انتظار دیسک برای ماشینهای دیگر میشود. در شبکه نیز اشباع رابط یا صفهای طولانی میتواند تأخیر را بالا ببرد.
الگوی Noisy Neighbor اغلب دورهای است. VPS صبحها سریع است، اما در ساعات کاری یا زمان اجرای پشتیبانگیری کند میشود. همین تغییرات زمانی یکی از تفاوتهای آن با کمبود دائمی منابع داخل سیستمعامل است. اگر با افزایش ترافیک خودتان، us بالا برود، احتمالاً برنامهتان CPU بیشتری میخواهد؛ اگر بدون تغییر بار شما، st یا iowait جهش کند، باید به میزبان و همسایهها شک کرد.
قبل از آزمون چه چیزهایی را ثبت کنیم؟
برای تشخیص درست، یک بار در زمان عادی و یک بار هنگام کندی اندازهگیری کنید. زمان، منطقه زمانی و وضعیت بار برنامه را یادداشت کنید. همچنین مشخصات اعلامشده سرویس را نگه دارید: تعداد vCPU، مقدار RAM، نوع دیسک و سقف ترافیک. در لینوکس ابتدا نسخه سیستم و تعداد هستههای قابل مشاهده را بررسی کنید:
uname -a
nproc
lscpu | egrep 'Model name|CPU\(s\)|Thread|Hypervisor'
free -h
lsblk -o NAME,TYPE,SIZE,ROTA
عبارت Hypervisor vendor در خروجی lscpu به شما میگوید ماشین روی چه محیطی اجرا میشود. ROTA=0 معمولاً دیسک بلوکی سریع مانند SSD را نشان میدهد، اما بهتنهایی تضمینکننده عملکرد خوب نیست؛ اشتراکگذاری ذخیرهساز همچنان میتواند گلوگاه باشد.
اندازهگیری با top و mpstat
دستور زیر نمایی لحظهای از CPU میدهد:
top
در خط %Cpu(s) به مقادیر زیر توجه کنید:
- us: زمان اجرای برنامههای کاربر
- sy: زمان صرفشده در هسته لینوکس
- wa: زمان انتظار برای عملیات ورودی و خروجی
- st: زمانی که هایپروایزر CPU را از ماشین شما گرفته است
برای مشاهده دقیقتر در طول زمان، بسته sysstat را نصب و mpstat را اجرا کنید:
# Debian/Ubuntu
sudo apt update && sudo apt install -y sysstat
mpstat -P ALL 1 10
در هر ثانیه یک نمونه ثبت میشود. اگر در چند نمونه پشت سر هم st بالا باشد، مسئله موقتی و قابل توجه است. افزایش همزمان wa میتواند به فشار ذخیرهساز اشاره کند. در VPSهای چند هستهای، ممکن است یک هسته st بالایی داشته باشد و میانگین کل پایین بماند؛ ستونهای هر CPU را جداگانه بخوانید. برای رصد بلندمدت بهجای اجرای دستی این دستورها هر بار، میتوانید راهاندازی مانیتورینگ سرور با Prometheus و Grafana را روی همین VPS بررسی کنید.
dstat برای دیدن ارتباط CPU، دیسک و شبکه
dstat چند شاخص را در یک صفحه کنار هم قرار میدهد و برای مشاهده الگوهای دورهای مفید است:
sudo apt install -y dstat
dstat -cdnm --top-cpu --top-io 1 20
ستون CPU مقدارهای usr, sys, idl, wai و stl را نمایش میدهد. stl همان Steal Time است. در بخش دیسک، افزایش خواندن و نوشتن همراه با wai بالا نشان میدهد پردازنده منتظر ذخیرهساز است. بخش شبکه نیز کمک میکند تشخیص دهید کندی برنامه از اشباع شبکه داخلی ناشی میشود یا خیر.
برای ثبت خروجی و مقایسه در دو ساعت مختلف:
dstat -cdnm 60 30 --output /tmp/vps-check.csv
این فایل را در زمان عادی و زمان شلوغ تولید کنید. یک مشاهده منفرد برای تصمیمگیری کافی نیست؛ الگوی تکرارشونده ارزش بیشتری دارد.
آزمون پردازنده با sysbench
برای مقایسه نسبی عملکرد CPU، از sysbench استفاده کنید. این آزمون را زمانی اجرا کنید که سرویس تولیدی شما بار حساسی ندارد:
sudo apt install -y sysbench
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run
پارامتر total time و تعداد رویدادهای اجراشده را یادداشت کنید. سپس در ساعت دیگری با همان تعداد رشته آزمون را تکرار کنید. اختلاف زیاد بین دو اجرا، بدون تغییر در پیکربندی، میتواند از رقابت برای CPU یا نوسان میزبان خبر دهد.
برای نتیجه قابل اعتماد، آزمون را چند بار و با فاصله انجام دهید. عدد یک VPS را با سرور دیگری که تعداد هسته و مدل CPU متفاوتی دارد مستقیماً مقایسه نکنید. هدف اصلی، شناخت ثبات همان سرویس است. هنگام اجرای آزمون، همزمان mpstat را در پنجرهای دیگر باز کنید تا ببینید st بالا میرود یا خیر:
mpstat 1
اگر sysbench کندتر شود و st افزایش پیدا کند، شواهد قویتری از کمبود زمان CPU در سطح هایپروایزر دارید.
آزمون ساده دیسک و تشخیص iowait
برای بررسی ذخیرهساز، از ابزارهایی مانند fio استفاده میشود، اما اجرای آزمون نوشتن روی دیسک ممکن است روی سرویسهای در حال کار اثر بگذارد. برای بررسی کمخطرتر ابتدا وضعیت فعلی را ببینید:
iostat -xz 1 10
در خروجی به await و %util توجه کنید. await بالا یعنی درخواستها مدت زیادی در صف یا در حال اجرا بودهاند. %util نزدیک ۱۰۰ درصد نشان میدهد دیسک در تمام بازه مشغول بوده است. این شاخصها را همراه با wa در mpstat تفسیر کنید؛ هیچ عددی بهتنهایی علت را ثابت نمیکند. برای دیدن اینکه کدام پردازش بیشترین فشار I/O را ایجاد میکند، نصب iotop برای مانیتورینگ I/O دیسک در لینوکس کمک میکند.
جمعبندی نشانهها در یک جدول
| نشانه | مشاهده معمول | برداشت محتمل |
|---|---|---|
st پایدار بالاتر از ۵٪ | CPU آزاد به نظر میرسد اما برنامه کند است | رقابت شدید برای CPU یا overselling |
wa بالا و await زیاد | عملیات فایل متوقف یا آهسته است | فشار ذخیرهساز مشترک |
| کندی فقط در ساعتهای مشخص | صبح خوب، زمان شلوغ بد | Noisy Neighbor یا بار دورهای میزبان |
us بالا و st نزدیک صفر | پردازش خودتان CPU را پر کرده است | نیاز به بهینهسازی برنامه یا vCPU بیشتر |
| نتیجه sysbench با نوسان زیاد | زمان اجرا بین دفعات اختلاف دارد | منابع ناپایدار یا محدودیت هایپروایزر |
| RAM کم و swap فعال | si/so در dstat افزایش دارد | کمبود حافظه داخل VPS، نه لزوماً همسایه |
سرور مجازی ارزان را چگونه ارزیابی کنیم؟
قیمت پایین بهتنهایی بد نیست؛ مهم است بدانید کدام منابع اشتراکی هستند و چه سطحی از عملکرد تضمین میشود. پیش از خرید این پرسشها را از ارائهدهنده بپرسید؛ چکلیست خرید سرور مجازی و مقایسه ارزانترین سرور مجازی ایران هم مرور کاملتری از همین نکات میدهند:
نوع مجازیسازی و سهم CPU
KVM معمولاً جداسازی بهتری نسبت به محیطهای قدیمیتر ایجاد میکند، اما نام فناوری کافی نیست. درباره تعداد vCPU، مدل پردازنده میزبان و سیاست overselling سؤال کنید. ارائهدهندهای که شاخصهای عملکرد و محدودیتها را شفاف اعلام میکند، برای سرویسهای حساس انتخاب مطمئنتری است.
ذخیرهساز و پشتیبانگیری
SSD یا NVMe بودن دیسک، سرعت پایه را بهتر میکند، اما نوع RAID، اشتراکگذاری آرایه و سیاست پشتیبانگیری نیز مهم است. پشتیبانگیری نباید باعث افت شدید دورهای سرویس شما شود.
امکان آزمون و جابهجایی
دوره بازگشت وجه یا امکان انتقال به نود دیگر ریسک خرید را کاهش میدهد. پس از تحویل VPS، در چند زمان مختلف mpstat، iostat و sysbench را اجرا کنید و نتایج را ثبت کنید. اگر st یا زمان پاسخ بهطور مداوم نامناسب است، مستندات اندازهگیری را برای پشتیبانی بفرستید.
پشتیبانی فنی
پشتیبانی باید بتواند درباره نود میزبان، فشار دیسک و جابهجایی ماشین بررسی انجام دهد. پاسخ کلی مانند «منابع شما کافی است» بدون بررسی steal یا iowait مشکل را حل نمیکند.
چه زمانی ارتقا دهیم و چه زمانی ارائهدهنده را عوض کنیم؟
اگر us بالا، RAM پر و swap فعال است، ارتقای منابع یا بهینهسازی برنامه منطقی است. اما اگر مصرف شما پایین باشد و st یا await در ساعات مختلف بالا بماند، افزایش vCPU ممکن است فقط هزینه را بیشتر کند؛ مشکل در نود میزبان یا سیاست اشتراکگذاری است. در این وضعیت ابتدا درخواست انتقال به نود خلوتتر بدهید. اگر الگو تکرار شد، جابهجایی به ارائهدهندهای با منابع اختصاصیتر تصمیم بهتری است. اگر میخواهید بین سرور ابری، VPS و سرور اختصاصی تصمیم بگیرید، راهنمای خرید سرور ابری تفاوتها را باز میکند.
برای سرویسهایی مانند پایگاهداده پرتراکنش، CI/CD یا پردازش ویدئو، تفاوت چند درصد Steal Time میتواند مستقیماً روی زمان پاسخ و هزینه عملیاتی اثر بگذارد. برای یک وبسایت کمترافیک، نوسان کوتاه شاید قابل قبول باشد؛ معیار را بر اساس SLA و حساسیت کسبوکار تعیین کنید.
نتیجهگیری
کندی یک سرور مجازی ارزان همیشه از کمبود اسمی CPU یا RAM ناشی نمیشود. CPU Steal Time نشان میدهد هایپروایزر چه مقدار از زمان پردازنده را به ماشینهای دیگر داده است و Noisy Neighbor میتواند همین رقابت را به دیسک و شبکه هم بکشاند. با ثبت خروجی top، mpstat، dstat، iostat و اجرای تکرارشونده sysbench میتوانید تفاوت میان بار داخلی و مشکل زیرساختی را مشخص کنید.
اگر ثبات عملکرد برایتان مهم است، هنگام انتخاب VPS فقط به تعداد هسته و قیمت ماهانه نگاه نکنید. شفافیت منابع، نوع ذخیرهساز، کیفیت پشتیبانی و امکان جابهجایی نود را هم بررسی کنید. برای شروع میتوانید مشخصات سرورهای ابری آریانت را ببینید و پلنی را انتخاب کنید که با بار واقعی سرویس شما سازگار باشد.
