سایز درست سرور مجازی را تیپ سایت و مصرف واقعی تعیین میکند، و بهترین استراتژی خرید، سهمرحلهای است: با اندازهٔ منطقیِ تیپ خودتان شروع کنید، یک ماه مصرف واقعی را پایش کنید، بعد پلهپله تنظیم کنید. برای اینکه «اندازهٔ منطقی» عدد داشته باشد: سایت وردپرسی شرکتی با دو گیگ رم و دو هسته شروع خوبی دارد و فروشگاه ووکامرسی فعال از چهار گیگ به پایین نیاید. بقیهٔ این راهنما همین اعداد را باز میکند: هر منبع دقیقاً چه چیزی را تعیین میکند، جدول پیشنهادی برای پنج تیپ رایج، و نشانههایی که میگویند سایز را اشتباه گرفتهاید. این مقاله دربارهٔ «چقدر بخرم» است؛ اگر هنوز بین سرور مجازی و اختصاصی ماندهاید، اول راهنمای انتخاب نوع سرور را بخوانید و اگر سوالتان محل سرور است، راهنمای ایران یا آلمان را.
چهار منبع اصلی؛ هرکدام چه چیزی را تعیین میکند؟
پردازنده (تعداد هسته) سقف همزمانی شماست: هر بازدید داینامیک، یک واحد کار PHP و چند کوئری دیتابیس است و وقتی درخواستها از توان هستهها جلو بزنند، صف تشکیل میشود و زمان پاسخ بالا میرود. سایت پربازدیدِ کممحاسبه، به هستههای بیشتر بهتر جواب میدهد تا هستههای سریعتر.
رم، خانهٔ سه مصرفکنندهٔ بزرگ است: دیتابیس، واحدهای PHP و کش. سهم دیتابیس تعیینکنندهترین است؛ MySQL و MariaDB بیشترین سودشان را از بافر InnoDB میبرند و مستند رسمی MariaDB توصیه میکند روی سرورِ دیتابیسمحور، بخش بزرگی از رم به همین بافر برسد تا خواندنها از حافظه جواب داده شوند، نه از دیسک. قاعدهٔ سرانگشتی ما: روی سرور ترکیبی (وب + دیتابیس)، حدود نیمی از رم باید بعد از راهاندازی کامل، آزاد یا در اختیار کش سیستم باشد؛ کمتر از این یعنی جای مانور ندارید.
دیسک دو بُعد دارد که نباید با هم قاطی شوند: سرعت و فضا. سرعت (NVMe در برابر SSD معمولی) مستقیم روی کوئریهای دیتابیس و زمان TTFB اثر میگذارد و برای فروشگاه، تفاوتش محسوس است. فضا را هم دستکم نگیرید: لاگها، بکاپهای محلی و آپلودها بیسروصدا رشد میکنند و دیسکِ پر، سایت را ناگهانی میخواباند. و شبکه: حجم ترافیک ماهانه و سرعت پورت، برای سایتهای پرتصویر و پردانلود زودتر از بقیهٔ منابع به سقف میرسد.
جدول پیشنهادی؛ پنج تیپ رایج
| تیپ سایت | رم | هسته | دیسک | نکتهٔ کلیدی |
|---|---|---|---|---|
| وبلاگ و سایت شرکتی وردپرسی | ۲ گیگ | ۲ | ۲۵ گیگ NVMe | با کش خوب، همین سایز تا ترافیک قابلتوجه جواب میدهد |
| فروشگاه ووکامرسی فعال | ۴ تا ۸ گیگ | ۴ | ۵۰ گیگ NVMe به بالا | سبد خرید کش نمیشود؛ همزمانی واقعی بالاتر از آمار بازدید است |
| چند سایت روی یک سرور | ۴ تا ۸ گیگ | ۴ | ۸۰ گیگ به بالا | یک سایتِ مشکلدار میتواند بقیه را هم پایین بکشد؛ ایزولهسازی مهمتر از عدد |
| اپلیکیشن و API اختصاصی | ۴ گیگ به بالا | ۲ تا ۴ | بسته به داده | پروفایل مصرف را از محیط تست بگیرید؛ حدس نزنید |
| ابزارهای همیشهروشن (ربات، ترید) | ۱ تا ۲ گیگ | ۱ تا ۲ | ۲۵ گیگ | پایداری و آپتایم مهمتر از قدرت؛ راهنمای سرور ترید را ببینید |
این اعداد نقطهٔ شروعاند، نه حکم؛ بعد از یک ماه پایش مصرف واقعی، جای درستشان معلوم میشود. پلنهای موجود را میتوانید در صفحهٔ سرور مجازی برتینا با همین چارچوب مقایسه کنید.
محاسبهٔ سرانگشتی رم؛ با یک مثال واقعی
اگر جدول بالا برایتان کلی است، این محاسبه را با اعداد خودتان تکرار کنید. رم لازم، جمع چهار سهم است: سیستمعامل و سرویسهای پایه حدود نیم گیگ؛ واحدهای PHP هرکدام بین شصت تا صد و بیست مگابایت که ضربدر همزمانی هدفتان میشود؛ بافر دیتابیس به اندازهٔ دادهٔ داغ (جدولهای پراستفاده و ایندکسها)؛ و حاشیهای برای کش سیستمعامل.
مثال: فروشگاهی که در ساعت اوج، بیست بازدیدکنندهٔ فعالِ همزمان دارد. بیست واحد PHP ضربدر حدود صد مگابایت یعنی حدود دو گیگ؛ دیتابیس فروشگاهی با چند ده هزار محصول و سفارش، حدود یک گیگ بافر میخواهد تا کوئریهای پرتکرار از حافظه جواب بگیرند؛ نیم گیگ سیستم و نیم گیگ حاشیه هم رویش. جمع: حدود چهار گیگ، که با سطر دوم جدول هم میخواند. همین محاسبه نشان میدهد چرا «بازدید ماهانه» معیار خوبی برای سایزینگ به حساب نمیآید: چیزی که رم را تعیین میکند همزمانیِ لحظهٔ اوج است، و دو سایت با بازدید ماهانهٔ یکسان میتوانند اوجهای کاملاً متفاوتی داشته باشند.
نکتهٔ بومی؛ سایزینگ برای الگوی ترافیک ایران
الگوی ترافیک سایتهای ایرانی یک ویژگی دارد که در سایزینگ باید دیده شود: پیکهای تیز کمپینی. ارسال پیامک انبوه، استوری پرفروش یا کد تخفیف ساعتی، همزمانی را در چند دقیقه چند برابر میکند؛ سروری که برای میانگین سایز شده، دقیقاً وسط بهترین ساعت فروش کم میآورد. اگر بازاریابی کمپینمحور دارید، یا سایز را برای پیک بگیرید یا پیش از هر کمپین، پلن را موقتاً یک پله بالا ببرید و بعد برگردانید؛ ترکیب این تصمیم با آمادهسازی کش و صفحهٔ فرود را در راهنمای آمادهسازی برای ترافیک ناگهانی نوشتهایم. موضوع محل سرور و مسیرهای بینالملل هم روی تجربهٔ همین پیکها اثر دارد که در راهنمای انتخاب موقعیتِ لینکشده در ابتدای مقاله بررسی شده است.
قبل از خرید، جواب این سه سوال را داشته باشید
لینوکس یا ویندوز؟ ویندوز سرور، خودش پیش از هر بار مصرفی شما حدود دو گیگ رم و فضای دیسک قابلتوجه میخواهد؛ اگر اپلیکیشن ویندوزی خاصی ندارید، لینوکس همان منابع را یک پله ارزانتر به خودِ سایت میرساند. کنترل پنل میخواهید؟ پنلهایی مثل cPanel راحتی میآورند و سهم رم و دیسک خودشان را هم برمیدارند؛ اگر مسیر پنل را میروید، راهنمای نصب cPanel روی سرور مجازی را ببینید و سهمش را در سایزینگ حساب کنید. و مدیریتشده یا خودمدیریت؟ سرور خودمدیریت یعنی بهروزرسانی، امنیت و بکاپ با شماست؛ اگر تیم فنی ندارید، هزینهٔ مدیریت را یا با سرویس مدیریتشده بدهید یا با وقت خودتان، ولی در هر حال جایی در بودجه دیده شود.
نشانههای سایز اشتباه؛ کوتاه و عملی
سه فرمان ساده، وضعیت را لو میدهد: free -h برای رم و سواپ، htop برای بار پردازنده، و df -h برای دیسک. سواپِ همیشه پر یعنی رم کم است؛ load average بالاتر از تعداد هستهها یعنی پردازنده صف دارد؛ و iowait بالا معمولاً یعنی دیسک کند یا دیتابیس بیایندکس. علائم بیرونیاش هم خطاهای ۵۰۲ و ۵۰۴ در اوج ترافیک است. فهرست کامل نشانهها و تصمیم ارتقا را در راهنمای تشخیص نیاز به ارتقای سرور مجازی نوشتهایم و اگر سرور مدام از دسترس خارج میشود، دلایل رایج crash سرور مجازی را هم ببینید؛ اینجا فقط این را اضافه میکنیم که پایش باید قبل از بحران راه افتاده باشد، با همان چیدمانی که در راهنمای مانیتورینگ سرور آمده.
خطاهای رایج سایزینگ
- خریدن سرورِ سال بعد در امروز: منابع خالی، پول خوابیده است و ارتقای پلهای در بیشتر پنلها چند دقیقه کار دارد. سایز را برای مصرف سه ماه آینده بگیرید، نه رویای سه سال بعد.
- درمان کد کند با رم بیشتر: اگر گلوگاه، کوئری بیایندکس یا افزونهٔ سنگین است، دو برابر کردن رم فقط هزینه را دو برابر میکند. اول بهینهسازی سرور مجازی، بعد ارتقا.
- فراموش کردن سهم سیستم و پنل: رم اسمی پلن، تماماً به خودِ سایت نمیرسد؛ سیستمعامل، پنل و سرویسهای جانبی سهمشان را اول برمیدارند.
- دیسک را فقط با حجم امروز حساب کردن: لاگ، بکاپ محلی و آپلودها رشد میکنند؛ دیسکی بگیرید که بعد از استقرار کامل، دستکم نیمیاش خالی بماند.
- ارتقای بدون اندازهگیری: قبل و بعد از هر تغییر سایز، همان سه فرمان بالا را ثبت کنید؛ ارتقایی که اثرش اندازهگیری نشود، تصمیم بعدی را هم کور میکند.
مسیر رشد؛ از هاست اشتراکی تا سرور اختصاصی
صادقانه از دو سر طیف شروع کنیم. اگر سایت وردپرسی کوچکی دارید و از سرور فقط «جای سایت» میخواهید، هاست اشتراکی با هزینه و دردسر کمتر همان کار را میکند؛ سرور مجازی وقتی معنا دارد که دسترسی روت، سرویس اختصاصی یا ایزوله بودن منابع لازمتان باشد. در سر دیگر طیف، وقتی به سایزهای بالای جدول رسیدید و باز هم کم آوردید، پرش بعدی سرور اختصاصی است؛ مقایسهٔ منصفانهٔ این دو را در راهنمای سرور اختصاصی یا مجازی نوشتهایم.
در میانهٔ طیف، قاعدهٔ رشد ساده است: پلهپله ارتقا بدهید و قبل از هر پله، یک نسخهٔ کامل نگه دارید؛ اسنپشات برای برگشت سریع خوب است ولی جای بکاپ مستقل را نمیگیرد، به دلایلی که در راهنمای استراتژی بکاپ آمده. و اگر فروشگاه ووکامرسی در حال رشدی دارید، قبل از بزرگتر کردن سرور، بهینهسازی ووکامرس در مقیاس بالا را بخوانید؛ بخشی از نیاز به منابع، با تنظیم درست خودِ فروشگاه حل میشود.
سوالات متداول دربارهٔ انتخاب منابع سرور مجازی
برای یک سایت وردپرسی معمولی چند گیگ رم کافی است؟
دو گیگ با دو هسته، برای سایت شرکتی یا وبلاگ با کشِ درست، شروع مطمئنی است؛ پیشنیاز رسمی وردپرس از این هم پایینتر است، ولی فاصلهٔ «اجرا میشود» تا «راحت کار میکند» را رم و دیسک سریع پر میکنند. اگر بعد از یک ماه، سواپ خالی و رم نیمهآزاد بود، سایز درست است.
NVMe واقعاً فرق میکند یا اسم تجاری است؟
برای کارهای دیتابیسمحور فرقش واقعی و اندازهگیریشدنی است: تأخیر خواندن و نوشتن NVMe چند برابر کمتر از SSD معمولی است و این مستقیم در زمان کوئریها و TTFB دیده میشود. برای سایت ایستا یا کمترافیک، تفاوت محسوس کمتری دارد و نباید فقط به خاطر NVMe پلن گرانتر بخرید.
رم بیشتر همیشه یعنی سایت سریعتر؟
فقط وقتی که گلوگاه واقعاً رم باشد. رمی که به بافر دیتابیس و کش میرسد سرعت میسازد؛ رمی که خالی میماند فقط هزینه است و رمی که صرف پوشاندن کد کند میشود، مشکل را عقب میاندازد. اول با پایش مطمئن شوید گلوگاه کجاست.
سرور مجازی ویندوز چقدر منابع بیشتری میخواهد؟
حدود دو گیگ رم و فضای دیسک قابلتوجه را قبل از بار کاری خودتان کنار بگذارید؛ یعنی جایی که لینوکس با دو گیگ راحت است، ویندوز از چهار گیگ شروع میشود. اگر وابستگی ویندوزی ندارید، همین تفاوت، پول واقعی است.
چند سایت را میشود روی یک سرور مجازی گذاشت؟
محدودیت فنی سفتوسختی وجود ندارد؛ محدودیت واقعی، ریسک مشترک است. هر سایت اضافه، هم منابع میبرد هم سطح خطا را بالا میبرد: افزونهٔ خراب یا حملهٔ روی یکی، بقیه را هم کند یا ساقط میکند. برای چند سایت جدی، رم و دیسک را جمع بزنید، یک پله بالاتر بگیرید و سایت درآمدزای اصلی را اگر شد جدا نگه دارید.
محل سرور در سایزینگ اثر دارد؟
روی خودِ اعداد منابع، تقریباً هیچ؛ روی تجربهٔ کاربر، زیاد. مخاطب داخل ایران با سرور ایران، تأخیر کمتری میبیند و مخاطب جهانی با سرور خارج. اول با راهنمای انتخاب موقعیت محل را ببندید، بعد با همین مقاله سایز را.
هستهٔ بیشتر بهتر است یا هستهٔ سریعتر؟
به الگوی بار بستگی دارد. سایتی با بازدیدکنندهٔ زیاد و صفحههای سبک، از تعداد هسته سود میبرد چون کارش موازیشدنی است؛ کارهای تکرشتهای سنگین، مثل ساخت گزارش بزرگ یا ایمپورت حجیم، به سرعت تکهسته حساسترند. برای بیشتر سایتهای وردپرسی و فروشگاهی، اول تعداد هسته را تأمین کنید و فرکانس را معیار دوم بگیرید؛ و به خاطر داشته باشید که در سرور مجازی، کیفیت زیرساخت میزبان روی توان واقعی هر هسته اثر میگذارد، پس مقایسهٔ صرفاً عددی پلنهای دو ارائهدهنده، همیشه منصفانه از آب درنمیآید.
ارتقای منابع باعث قطعی سایت میشود؟
در بیشتر زیرساختها، تغییر رم و هسته یک ریاستارت کوتاه میخواهد و تغییر دیسک، بسته به روش، بیشتر. برنامهاش را برای ساعت کمترافیک بگذارید، قبلش نسخهٔ کامل بگیرید و بعدش با همان سه فرمان پایش، نتیجه را ثبت کنید تا پلهٔ بعدی حسابشده باشد.
