راهنمای انتخاب منابع VPS؛ CPU، RAM، دیسک و ترافیک
سایز درست VPS از تعداد بازدید شروع نمیشود؛ از نوع کار شروع میشود. این راهنما CPU، RAM، Storage و Network را به رفتار واقعی اپلیکیشن وصل میکند و یک روش مرحلهای برای انتخاب کانفیگ میدهد.
پاسخ کوتاه: VPS را از روی چه عددی انتخاب کنیم؟
برای انتخاب منابع سرور مجازی هیچ عدد واحدی وجود ندارد. منابع سرور مجازی باید از روی Workload تعیین شوند: چه چیزی پردازش میکنید، چه حجمی در حافظه نگه میدارید، چقدر I/O دارید و چه مقدار داده از شبکه عبور میکند.
بهجای سؤال «برای ۱۰۰ هزار بازدید چقدر RAM لازم است؟» بپرسید «در Peak چند Request همزمان داریم، هر Request چه CPU/Memory میگیرد و Cache Hit Rate چقدر است؟»
دو سایت با بازدید مساوی میتوانند مصرف منابع کاملاً متفاوتی داشته باشند. یک API سبک Cached ممکن است با منابع کم پاسخ دهد، درحالیکه گزارشگیری دیتابیس یا پردازش تصویر با ترافیک کمتر CPU و I/O بیشتری بخواهد.
vCPU دقیقاً چه چیزی را نشان میدهد؟
vCPU سهم پردازشی ماشین مجازی است، اما نام آن بهتنهایی Performance را تضمین نمیکند. نسل CPU، Clock، معماری، سیاست اشتراک هسته و الگوی Burst روی خروجی اثر دارند. برای کارهای CPU-bound مثل Encoding، Build یا گزارش سنگین، تست واقعی مهمتر از شمارش هسته است.
اگر سرویس بیشتر وقت منتظر Database یا Network است، اضافهکردن vCPU ممکن است تغییر کمی ایجاد کند. قبل از ارتقا Load Average، CPU Usage، Steal/Wait و زمان سرویسهای وابسته را بررسی کنید.
RAM؛ ظرفیت فعال سرویسهای شما
RAM برای Kernel، Serviceها، Application، Cache و Buffer استفاده میشود. کمبود حافظه میتواند باعث Swap شدید یا OOM شود. در مقابل، RAM بسیار بیشتر از Working Set پروژه هزینه بدون استفاده ایجاد میکند.
برای تخمین، مصرف Idle سیستمعامل + مصرف سرویسهای پایه + Peak اپلیکیشن + حاشیه امن را جمع کنید. اگر Database روی همان VPS است، Buffer Pool و Connectionها را نیز جدا حساب کنید.
Swap نجاتدهنده است یا هشدار؟
Swap میتواند در Spike کوتاه از Crash فوری جلوگیری کند، اما جای RAM نیست. اگر سرویس دائماً صفحات حافظه را بین RAM و Disk جابهجا میکند، Latency بالا میرود. Swap Usage را همراه با Swap In/Out ببینید؛ صرفاً وجود عدد استفادهشده بهتنهایی تشخیص کافی نیست.
Storage؛ ظرفیت با Performance فرق دارد
دو سؤال جدا دارید: چند گیگابایت فضا لازم است و دیسک با چه Latency/IOPS باید پاسخ دهد؟ پروژهای با ۲۰GB Database تراکنشی ممکن است به I/O حساستر از File Server با ۵۰۰GB آرشیو باشد.
| Workload | شاخص مهمتر | چرا؟ |
|---|---|---|
| Database OLTP | Latency و Random IOPS | عملیات کوچک و پرتعداد |
| Backup/Archive | Throughput و Capacity | فایلهای بزرگ و ترتیبی |
| Build Server | IOPS + CPU | فایلهای زیاد و Compile |
| Static File Server | Throughput + Network | انتقال حجم داده |
NVMe همیشه اولویت اول نیست
در VPS خارجی FluxCDN Storage مبتنی بر NVMe ارائه میشود، اما حتی NVMe هم اگر Application منتظر API کند یا CPU اشباع باشد، معجزه نمیکند. Storage سریع باید در زنجیره Bottleneck دیده شود. برای Workload دیتابیس، Queue و Build ارزش آن بیشتر از صفحه Static Cached قابل مشاهده است.
ترافیک ماهانه با سرعت پورت متفاوت است
Traffic مقدار داده مجاز در دوره است؛ Port Speed ظرفیت لینک است. پروژه میتواند ترافیک ماهانه کم اما Burst بالا داشته باشد یا برعکس. برای تخمین ترافیک، خروجی اصلی، Backup، Replication، Download و Log Shipping را جمع کنید.
در VPS ایران FluxCDN پلن پایه ۱۰۰GB ترافیک دارد و ترافیک اضافه نرخ جداگانه دارد. در لوکیشنهای خارجی مقدار ترافیک به کانفیگ وابسته است. اعداد را مستقیماً از صفحه همان سرویس بررسی کنید.
چطور ترافیک را تقریبی حساب کنیم؟
فرمول ساده برای Web Response: تعداد درخواست × متوسط حجم Response. اما CDN، Browser Cache، Upload، API و Botها نتیجه را تغییر میدهند. اگر هر بازدید ۲MB از Origin بگیرد و ۵۰ هزار بازدید داشته باشید، فقط همین بخش حدود ۱۰۰GB خروجی است؛ قبل از اضافهکردن Backup و سایر سرویسها.
برای سرویس جدید، ابتدا با Log یا Analytics مشابه تخمین بزنید و ۲۰ تا ۳۰ درصد Headroom قرار دهید؛ سپس پس از یک دوره واقعی عدد را اصلاح کنید.
جدول شروع برای چند سناریو
| سناریو | نقطه شروع آزمایشی | چه چیزی باید مانیتور شود؟ |
|---|---|---|
| Reverse Proxy سبک | ۱–۲ vCPU، ۱–۲GB RAM | Network، Connection، CPU |
| API کوچک | ۲ vCPU، ۲–۴GB RAM | CPU، Memory، P95 Latency |
| WordPress مستقل | ۲–۴ vCPU، ۴–۸GB RAM | PHP Worker، DB، Cache، I/O |
| Database کوچک | ۲–۴ vCPU، ۴–۸GB RAM | Buffer Hit، IOPS، Connections |
| Build/CI | ۴+ vCPU، ۴–۸GB RAM | CPU time، Disk I/O، Duration |
این جدول تضمین ظرفیت نیست. هدف آن ساختن نقطه شروع برای Benchmark است؛ داده واقعی پروژه باید کانفیگ نهایی را تعیین کند.
Peak را از Average جدا کنید
Average Usage میتواند سالم باشد اما در ساعت Peak سرویس Fail کند. برای سایزینگ منابع سرور مجازی، P95/P99 مصرف CPU، Memory و Response Time را ببینید. اگر Spike کوتاه و قابل Cache است، شاید Optimization بهتر از ارتقای دائمی باشد. اگر Peak هر روز تکرار میشود، ظرفیت باید آن را پوشش دهد.
Headroom چقدر باشد؟
ظرفیت ۱۰۰ درصدی طراحی شکننده است. Headroom برای Deployment، Traffic Spike، Maintenance و Jobهای دورهای لازم است. عدد ثابت جهانی وجود ندارد، اما اگر در حالت عادی CPU و RAM دائماً نزدیک سقفاند، فرصت جذب Spike ندارید.
بهجای قانون «همیشه ۵۰٪ آزاد»، Threshold را بر اساس SLA و سرعت ارتقای زیرساخت تعیین کنید. سرویسی که در چند دقیقه Scale میشود میتواند Headroom کمتری از سیستمی داشته باشد که ارتقایش نیازمند Migration است.
Database روی همان VPS یا جدا؟
برای پروژه کوچک، نگهداشتن App و DB روی یک VPS ساده و اقتصادی است. با رشد، CPU و I/O دو سرویس با هم رقابت میکنند و Backup/Restart نیز دامنه اثر بزرگتری دارد. اگر Query Load یا نیاز Availability بالا رفت، جداکردن Database میتواند Observability و Scale را بهتر کند.
چه زمانی باید ارتقا دهید؟
- CPU در Peak پیوسته اشباع میشود و Queue ایجاد میکند.
- OOM یا Swap Thrashing دارید.
- Disk Latency و I/O Wait بالا است.
- Traffic به سقف دوره نزدیک میشود.
- Storage Growth فضای امن برای Backup و Update باقی نمیگذارد.
- Latency اپلیکیشن پس از Optimization هنوز با Resource Saturation همبستگی دارد.
ارتقا باید پاسخ به یک Metric باشد، نه واکنش به حس «سرور کند است».
چه زمانی نباید ارتقا دهید؟
اگر CPU پایین است اما یک API خارجی ۳ ثانیه زمان میبرد، RAM بیشتر مسئله را حل نمیکند. اگر Query بدون Index است، CPU بیشتر فقط Query بد را سریعتر مصرف میکند. اگر Cache خاموش است، ابتدا Cache را اصلاح کنید. ظرفیت و Optimization دو مسیر مکملاند، نه جایگزین هم.
روش عملی انتخاب پلن
- Workload و سرویسهای اصلی را فهرست کنید.
- مصرف فعلی یا Benchmark نمونه را ثبت کنید.
- Bottleneck محتمل را مشخص کنید.
- کانفیگ نزدیک به تخمین را انتخاب کنید.
- Load Test با سناریوی واقعی اجرا کنید.
- Headroom و هزینه Growth را بررسی کنید.
- پس از یک هفته داده، کانفیگ را دوباره ارزیابی کنید.
اگر هنوز مطمئن نیستید، سرور ساعتی برای تست کانفیگ خارجی میتواند هزینه آزمایش را کنترل کند.
Concurrency مهمتر از تعداد کاربر ثبتشده است
تعداد User یا Visit ماهانه بهتنهایی CPU و RAM را تعیین نمیکند. چیزی که ظرفیت را فشار میدهد تعداد کار همزمان و هزینه هر کار است. ۱۰ هزار کاربر که در طول روز پخش شدهاند میتوانند سبکتر از ۵۰۰ کاربر همزمان در یک دقیقه باشند.
برای API، Requests per Second و P95 Service Time را ثبت کنید. برای Worker، تعداد Job همزمان و Duration مهم است. برای Database، Active Connection و Query Cost را ببینید. این Metricها مستقیمتر به منابع وصل میشوند.
Cache چگونه سایز موردنیاز را عوض میکند؟
Cache میتواند CPU و Database Load را بهشدت کم کند، اما خودش RAM مصرف میکند. Page Cache، Object Cache و OS Page Cache هرکدام Working Set متفاوتی دارند. اگر Cache Hit Rate بالا است، ارتقای RAM برای Cache گاهی از vCPU بیشتر اثر دارد؛ اگر Hit Rate پایین است، ابتدا دلیل Miss را بررسی کنید.
سایزینگ باید در وضعیت Warm Cache و Cold Cache هر دو تست شود، چون Restart یا Deploy میتواند موقتاً فشار را بالا ببرد.
Growth را به واحد قابل سنجش تبدیل کنید
بهجای «سایت در حال رشد است»، نرخ رشد بنویسید: Database ماهانه ۵GB، Traffic ماهانه ۱۵٪، Job Queue دو برابر در فصل فروش. سپس ببینید کانفیگ فعلی چند ماه Headroom دارد.
این روش زمان Review را نیز مشخص میکند. اگر Storage با نرخ فعلی سه ماه دیگر به ۸۰٪ میرسد، تصمیم ارتقا را قبل از بحران برنامهریزی میکنید.
Baseline تست را ثبت کنید
هر Benchmark باید نسخه Application، Dataset، تعداد User مجازی، مدت Warm-up و Region Client را ثبت کند. بدون این اطلاعات، مقایسه دو کانفیگ قابل تکرار نیست. یک تغییر کوچک در Cache یا Dataset ممکن است بیش از اضافهشدن یک vCPU روی نتیجه اثر بگذارد.
هدف Benchmark انتخاب «بزرگترین» سرور نیست؛ یافتن ارزانترین کانفیگی است که SLA شما را با Headroom مناسب پاس میکند.
جمعبندی
انتخاب منابع سرور مجازی باید از رفتار برنامه شروع شود. CPU برای پردازش، RAM برای Working Set، Storage برای ظرفیت و I/O، و Traffic برای انتقال داده هستند. هر کدام Bottleneck متفاوتی میسازند و خرید بیشتر از یک منبع، کمبود منبع دیگر را جبران نمیکند.
برای کانفیگهای داخلی سرور مجازی ایران و برای NVMe و لوکیشنهای خارجی سرور مجازی خارج را بررسی کنید. اگر هنوز نمیدانید VPS اساساً برای شما مناسب است یا نه، مقاله VPS چیست را ابتدا بخوانید.