روی صفحهٔ خرید پلن ابری ایستاده‌اید و دو ستون می‌بینید: یکی نوشته «۴ vCPU / 8GB RAM / 80GB SSD» و دیگری «۲ vCPU / 8GB RAM / 80GB NVMe». اختلاف قیمت هم کم نیست. سؤال واقعی این است: کدام عدد در بار واقعی گلوگاه میشود؟ جواب کوتاه این است که تقریباً هیچ‌وقت آن عددی نیست که اول به آن نگاه می‌کنید.
vCPU دقیقاً چه چیزی را تضمین می‌کند
vCPU یک هستهٔ فیزیکی نیست. یک رشتهٔ زمان‌بندی‌شده روی هستهٔ فیزیکی است. وقتی پلنی می‌گوید ۴ vCPU، یعنی هایپروایزر به ماشین شما اجازه می‌دهد در هر لحظه چهار رشتهٔ اجرایی موازی داشته باشد. تضمین نمیکند که آن چهار رشته همیشه روی چهار هستهٔ خالی بنشینند.
روی لینوکس می‌توانید ببینید واقعاً چند هسته در اختیار دارید:
lscpu | grep -E '^CPU\(s\)|Model name|MHz'
nproc
cat /proc/cpuinfo | grep -c processorاگر nproc عدد ۴ برگرداند ولی lscpu زیر بار مدل CPU را با فرکانس پایین نشان بدهد، احتمالاً با هستههای اشتراکی طرف هستید. این بد نیست؛ فقط یعنی steal time را باید جدی بگیرید:
top -bn1 | head -5
# ستون %st را ببینیدعدد %st بالای ۵ درصد به‌طور مداوم یعنی ماشین شما منتظر نوبت CPU است. زیر ۱ درصد یعنی مشکل جای دیگری است و ارتقای vCPU پول دور ریختن است.
چه زمانی vCPU بیشتر واقعاً کمک می‌کند
بارهای CPU-bound: کامپایل کد، رمزنگاری TLS در حجم بالا، پردازش تصویر، اجرای مدل‌های کوچک. اگر load average به‌طور پایدار از تعداد vCPU بیشتر است و %st پایین است، ارتقا منطقی است. اگر %st بالاست، مشکل در همسایگی است نه در تعداد.
رم: عددی که همیشه صادق است، ولی نه به آن شکلی که فکر می‌کنید
رم اختصاصی است. ۸ گیگابایت یعنی ۸ گیگابایت، و این تنها عددی در پلن است که تقریباً هیچ ابهامی ندارد. اما دو نکته هست که در عمل آدم‌ها را غافلگیر می‌کند.
- رم بافر و کش هسته جدا حساب میشود. اگر
free -hمی‌زنید و ستونavailableرا نمی‌بینید، دارید عدد اشتباه را می‌خوانید.usedبالا باavailableبالا یعنی سیستم سالم است. - swap روی دیسک شبکه‌ای فاجعه است. اگر پلن شما swap دارد و روی storage اشتراکی نشسته، هر بار swap-in یک رفت‌وبرگشت I/O است. با
vmstat 1ستونsiوsoرا ببینید؛ هر عدد غیرصفر پایدار یعنی کمبود رم دارید، نه کمبود CPU.
یک قاعدهٔ سرانگشتی که در عمل جواب می‌دهد: برای MySQL یا PostgreSQL، رم را طوری ببندید که innodb_buffer_pool_size حدود ۶۰ تا ۷۰ درصد رم کل شود. اگر پلن ۴ گیگ دارید و دیتابیس ۳ گیگ بافر می‌خواهد، وب‌سرور و PHP-FPM چیزی برای نفس کشیدن ندارند. اینجا ارتقای رم درست است، نه ارتقای CPU.
نوع دیسک: جایی که مشخصات پلن ابری دروغ نمی‌گوید ولی کم می‌گوید
«۸۰GB SSD» یک عدد ظرفیت است، نه یک عدد کارایی. دو پلن با ظرفیت یکسان می‌توانند در IOPS ده برابر تفاوت داشته باشند. این تفاوت را در مشخصات نمی‌بینید، در iostat می‌بینید.
iostat -x 1 5
# ستون‌های %util و await را ببینیداگر await روی دیسک اصلی به‌طور مداوم بالای ۲۰ میلی‌ثانیه است و %util نزدیک ۱۰۰، مشکل ظرفیت نیست؛ مشکل IOPS است. NVMe در بار تصادفی معمولاً چند برابر SATA SSD عملیات در ثانیه می‌دهد، ولی در بار ترتیبی (مثل خواندن یک فایل بزرگ) تفاوت خیلی کمتر از آن چیزی است که تبلیغات می‌گوید.
| نوع دیسک | مناسب برای | کجا کم می‌آورد |
|---|---|---|
| SATA SSD | وب‌سایت معمولی، فایلهای لاگ | دیتابیس با نوشتن تصادفی سنگین |
| NVMe | دیتابیس، صف پیام، کش | هزینه؛ و بار ترتیبی بزرگ |
| ذخیره‌سازی شبکه‌ای | بکاپ، آرشیو، اشتراک بین چند سرور | هر چیزی که latency زیر میلی‌ثانیه بخواهد |
اینجا اشتباه می‌کنند: کاربر دیسک را از SATA به NVMe ارتقا می‌دهد چون «دیتابیس کند است»، ولی کندی از کوئری بدون ایندکس بوده. علامتش این است که بعد از ارتقا، await پایین می‌آید ولی زمان پاسخ اپلیکیشن همان می‌ماند. اول EXPLAIN ANALYZE بزنید، بعد پول خرج دیسک کنید.
ترافیک: ماهانه، ورودی، خروجی
ترافیک پلن معمولاً به‌صورت «X ترابایت در ماه» نوشته میشود و تقریباً همیشه منظور خروجی است. ترافیک ورودی در اکثر ارائهدهندهها رایگان است چون برایشان گران نیست. اگر پلن شما ورودی را هم می‌شمارد، این را در قرارداد ببینید، نه در صفحهٔ فروش.
نکتهٔ عملی: ترافیک را با vnstat یا iftop خودتان اندازه بگیرید، نه با پنل.
vnstat -m
iftop -i eth0 -nاگر ترافیک خروجی‌تان مدام از سقف می‌زند، دو راه دارید: پلن با ترافیک بیشتر، یا انتقال فایلهای ثابت به یک فضای ذخیره‌سازی آبجکت و سرو کردنشان از شبکهٔ توزیع محتوا. راه دوم در حجم بالا تقریباً همیشه ارزان‌تر تمام میشود، چون ترافیک CDN معمولاً جدا حساب میشود و از سرور اصلی عبور نمیکند.
پلن را چطور بخوانیم تا بعداً پشیمان نشویم
- قبل از خرید، بار واقعی خودتان را اندازه بگیرید. یک هفته
vmstatوiostatلاگ کنید. - گلوگاه را پیدا کنید:
%stبالا یعنی CPU،si/soغیرصفر یعنی رم،awaitبالا یعنی دیسک. - فقط همان منبعی را ارتقا دهید که گلوگاه است. ارتقای همزمان همه‌چیز یعنی پول اضافه برای چیزی که مصرف نمی‌شود.
- قبل از هر تغییر، اسنپ‌شات بگیرید. اسنپ شات در فضای ابری ارزان‌ترین بیمه‌ای است که می‌خرید.
یک تذکر دربارهٔ مقیاس‌دهی: اگر پلن را بزرگ می‌کنید، معمولاً به reboot نیاز دارید مگر اینکه ارائه‌دهنده hot-resize داشته باشد. برای بارهایی که نمی‌توانند قطع شوند، این را از قبل بپرسید. راهنمای مقیاس‌دهی منابع ابری بدون قطعی دقیقاً همین سناریو را پوشش می‌دهد.
و اگر بار شما افقی رشد می‌کند (چند نمونهٔ وب پشت لود بالانسر) نه عمودی، منطق خرید عوض میشود: به‌جای پلن غول، چند پلن متوسط با لود بالانسر و health check معمولاً هم ارزان‌تر است هم مقاوم‌تر. برای بارهای کانتینری هم کوبرنتیز مدیریت‌شده این کار را خودش انجام می‌دهد.
پرسش‌های پرتکرار
vCPU اشتراکی است یا اختصاصی؟
در بیشتر پلنهای ابری، vCPU اشتراکی است؛ یعنی رشتههای اجرایی شما روی هستههای فیزیکی مشترک زمانبندی میشوند. اگر پلن «اختصاصی» یا dedicated CPU باشد، این در مشخصات ذکر میشود و قیمتش هم معمولاً بالاتر است. برای تشخیص در عمل، ستون %st در top را ببینید؛ اگر پایدار بالای ۵ درصد است، سهم شما در عمل کمتر از عدد پلن است.
چرا با اینکه رم کافی دارم، سرور کند است؟
چون گلوگاه جای دیگری است. سه کاندیدای اصلی: %st بالا (کمبود سهم CPU)، await بالای دیسک (کمبود IOPS)، و کوئریهای بدون ایندکس. با vmstat 1 و iostat -x 1 هر سه را میشود در دو دقیقه رد یا تأیید کرد. ارتقای رم وقتی si و so صفر است، هیچ چیزی را بهتر نمیکند.
ترافیک ماهانه پلن شامل ورودی هم میشود؟
در اکثر ارائهدهندهها فقط خروجی حساب میشود و ورودی رایگان است، ولی این یک قرارداد است نه یک قانون فنی. اگر بار شما ورودیمحور است (مثلاً دریافت آپلود یا ingest لاگ)، این بند را در قرارداد بخوانید. اندازهگیری مستقل با vnstat -m روی سرور، مرجع قابل اتکاتری از پنل است.
NVMe همیشه بهتر از SSD است؟
نه. در بار ترتیبی سنگین (خواندن و نوشتن فایلهای بزرگ) تفاوت NVMe و SATA SSD خیلی کمتر از بار تصادفی است. NVMe وقتی ارزشش را دارد که IOPS تصادفی گلوگاه باشد: دیتابیس، صف پیام، کش. اگر گلوگاه کوئری یا CPU است، ارتقای دیسک فقط هزینه است.
قدم بعدی: قبل از هر ارتقا، یک هفته لاگ vmstat و iostat جمع کنید و ببینید کدام ستون قرمز است. اگر هنوز مطمئن نیستید کدام منبع گلوگاه است، راهنمای مانیتورینگ ابری و هشدار نقطهٔ شروع درستی است؛ بعد از آن، انتخاب پلن یک تصمیم مهندسی میشود نه یک حدس.