انتخاب سرور مجازی: چقدر CPU و رم لازم دارید؟

سرورت را بالا آورده‌ای، سایت هم روی آن جواب می‌دهد، اما هر چند ساعت یک‌بار TTFB از ۲۰۰ میلی‌ثانیه می‌پرد به دو ثانیه و بعد خودش برمی‌گردد. یا برعکس: ماهی چند صد هزار تومان برای منابعی می‌دهی که هیچ‌وقت از نصفشان استفاده نمی‌کنی. مسئلهٔ واقعی این نیست که «چقدر CPU و رم خوب است»؛ مسئله این است که کدام منبع اول تمام می‌شود و چطور قبل از خریدن بفهمی.

اول بفهم کدام منبع گلوگاه است، بعد انتخاب سرور مجازی کن

اکثر آدم‌ها برعکس عمل می‌کنند. اول یک پلن با ۴ vCPU و ۸ گیگ رم می‌خرند، بعد می‌فهمند مشکل از کوئری‌های MySQL بوده که با ایندکس درست حل می‌شد. تخمین منابع بدون داده، حدس است. با داده، حساب‌وکتاب ساده‌ای است.

قبل از هر چیز، روی همان سرور فعلی این را اجرا کن و یک هفته نگه دار:

vmstat 5 720 >> /var/log/vmstat.log
sar -u -r -d 5 1

ستون si و so در vmstat اگر عدد غیرصفر نشان می‌دهند، یعنی سیستم دارد swap می‌زند و رم کم است. ستون wa (iowait) بالای ۱۰ درصد یعنی دیسک گلوگاه است، نه CPU. این دو خط، نصف تصمیم خرید را برایت روشن می‌کند.

نشانه‌های کمبود هر منبع، جدا از هم

• کمبود CPU: load average به‌طور پایدار بالای تعداد vCPU می‌ماند، ولی iowait پایین است. سایت زیر بار همزمان کند می‌شود و بعد از افت ترافیک فوراً خوب می‌شود.
• کمبود رم: OOM killer در dmesg رد می‌گذارد. PHP-FPM یا MySQL بدون دلیل ری‌استارت می‌شوند. این را در لاگ به شکل Out of memory: Killed process می‌بینی.
• کمبود دیسک: iowait بالا، اما CPU بیکار. اگر روی HDD باشی این خیلی زودتر از آنچه فکر می‌کنی اتفاق می‌افتد.
• کمبود پهنای باند: هیچ‌کدام از بالا نیست، ولی دانلود فایل کند است. اینجا مشکل جای دیگری است.

یک نکته که کمتر گفته می‌شود: روی سرورهای مجازی، vCPU سهمیه است نه هستهٔ اختصاصی. اگر پلن ۴ vCPU می‌خری ولی هایپروایزر شلوغ باشد، ممکن است در ساعات پیک فقط معادل ۲ هسته بگیری. به همین دلیل steal time را در top چک کن؛ اگر بالای ۵ درصد بود، مشکل از کد تو نیست.

تخمین از روی ترافیک واقعی، نه از روی حدس

یک فرمول سرانگشتی که در عمل جواب می‌دهد: تعداد درخواست همزمان را حساب کن، نه بازدید روزانه. اگر سایتت روزی ۵۰٬۰۰۰ بازدید دارد و میانگین هر بازدید ۸ درخواست می‌سازد، یعنی ۴۰۰٬۰۰۰ درخواست در روز. پخش‌شده روی ۲۴ ساعت می‌شود حدود ۴.۶ درخواست در ثانیه. اما ترافیک سایت‌ها یکنواخت نیست؛ ضریب پیک را ۵ تا ۱۰ برابر بگیر. یعنی باید برای ۲۵ تا ۵۰ درخواست در ثانیه آماده باشی.

حالا بستگی دارد هر درخواست چقدر CPU می‌خورد. یک صفحهٔ وردپرس کش‌نشده با چند پلاگین سنگین ممکن است ۱۵۰ تا ۳۰۰ میلی‌ثانیه CPU مصرف کند. یک endpoint سادهٔ API زیر ۱۰ میلی‌ثانیه. با ۵۰ درخواست در ثانیه و ۲۰۰ میلی‌ثانیه CPU برای هرکدام، به ۱۰ هستهٔ کامل نیاز داری. این عدد را با کش کردن به‌شدت پایین می‌آوری.

این‌جا اشتباه می‌کنند: آدم‌ها برای دیتابیس رم کم می‌گیرند و بعد با innodb_buffer_pool_size پیش‌فرض ۱۲۸ مگابایت کار می‌کنند. نتیجه‌اش این است که هر کوئری به دیسک می‌رود و iowait می‌پرد بالا، درحالی‌که CPU تقریباً بیکار است. علائم را می‌بینند و می‌گویند «سرور ضعیف است» و می‌روند CPU بیشتر می‌خرند. اشتباه در تشخیص، پول را هدر می‌دهد.

کِی مقیاس عمودی جواب می‌دهد و کِی نه

تا یک جایی، بزرگ‌تر کردن همان سرور ساده‌ترین راه است. یک سرور با ۸ هسته و ۳۲ گیگ رم، بدون هیچ تغییری در معماری، بار را می‌گیرد. این را تا وقتی ترافیکت زیر چند برابر ظرفیت فعلی است انتخاب کن.

اما دو جا این راه می‌شکند. اول، وقتی به سقف پلن‌ها می‌رسی و دیگر بالاتر نمی‌رود. دوم، وقتی می‌خواهی بدون قطعی به ظرفیت بیشتر برسی؛ چون تغییر پلن معمولاً ری‌استارت می‌خواهد. اگر سایتت نمی‌تواند حتی دو دقیقه قطعی را تحمل کند، باید از همان اول معماری افقی بریزی. تفاوت این دو رویکرد را در مقیاس‌پذیری خودکار؛ افقی یا عمودی؟ راهنمای انتخاب درست با مثال عددی توضیح داده‌ام.

یک تلهٔ رایج: رم را بر اساس مصرف لحظه‌ای انتخاب نکن. مصرف لحظه‌ای در ساعت خلوت، نصف مصرف پیک است. اگر بر اساس ساعت خلوت بخری، در پیک swap می‌زنی و همه‌چیز کند می‌شود. همیشه بر اساس صدک ۹۵ مصرف تصمیم بگیر، نه میانگین.

دیسک را دست‌کم نگیر

روی سرور مجازی، نوع دیسک به‌اندازهٔ ظرفیتش مهم است. یک NVMe با ۱۰۰ گیگ، از یک SATA با ۵۰۰ گیگ برای دیتابیس سریع‌تر است. اگر IOPS برایت مهم است، قبل از خرید بپرس که دیسک از چه نوعی است و آیا سهمیهٔ IOPS دارد یا نه. بعضی ارائه‌دهنده‌ها IOPS را بین مشتری‌ها تقسیم می‌کنند و در ساعات شلوغی عدد واقعی خیلی پایین‌تر از چیزی است که در تبلیغات دیده‌ای.

برای تست واقعی، بعد از راه‌اندازی این را اجرا کن:

fio --name=randread --ioengine=libaio --rw=randread \
  --bs=4k --numjobs=4 --size=1G --runtime=60 --group_reporting

عدد iops در خروجی، همان چیزی است که در قرارداد خریده‌ای. اگر با آنچه انتظار داشتی فاصلهٔ زیادی دارد، همان هفتهٔ اول پیگیری کن.

پیکربندی اولیه بعد از انتخاب سرور مجازی

بعد از اینکه منابع را انتخاب کردی، سه کار را همان روز اول انجام بده. اول، swap را با vm.swappiness=10 تنظیم کن تا فقط در فشار واقعی استفاده شود. دوم، مانیتورینگ را قبل از اینکه مشکل پیدا شود راه بینداز؛ راهنمای عملی‌اش در مانیتورینگ سرور: راهنمای عملی پایش و هشداردهی هوشمند هست. سوم، برای فایل‌های استاتیک و بکاپ‌ها از فضای ذخیره‌سازی جدا استفاده کن تا دیسک اصلی سرور پر نشود.

اگر سایتت ترافیک تصویری یا فایلی دارد، فضای ذخیره‌سازی آبجکت را از همان اول جدا کن. این کار هم دیسک سرور را آزاد نگه می‌دارد و هم بکاپ‌گیری را ساده‌تر می‌کند. برای محتوای استاتیک هم یک شبکهٔ توزیع محتوا جلوی سرور بگذار؛ این کار می‌تواند تا نیمی از بار CPU را از دوش سرور بردارد، چون درخواست‌های استاتیک اصلاً به سرور تو نمی‌رسند.

اگر بار کاری‌ات واقعاً متغیر است و نمی‌خواهی برای پیک پول بدهی، به‌جای خرید یک سرور بزرگ، از زیرساختی استفاده کن که بتوانی منابع را بر اساس تقاضا بالا و پایین ببری. زیرساخت ابری (IaaS) سرورنت همین انعطاف را می‌دهد؛ اما توجه کن که مقیاس‌پذیری خودکار بدون مانیتورینگ درست، فقط هزینه را بیشتر می‌کند.

پرسش‌های پرتکرار

برای یک سایت وردپرسی معمولی چند هسته CPU و چند گیگ رم لازم است؟

برای سایتی با ترافیک متوسط و کش فعال، ۲ هستهٔ CPU و ۴ گیگ رم نقطهٔ شروع منطقی است. اگر از کش صفحه و کش آبجکت استفاده می‌کنی، همین مقدار تا چند برابر ترافیک بیشتر جواب می‌دهد. رم معمولاً زودتر از CPU تمام می‌شود، پس اگر مجبوری بین این دو یکی را بیشتر بگیری، رم را انتخاب کن.

چطور بفهمم مشکل از کمبود رم است یا CPU؟

اگر iowait پایین است ولی load average بالای تعداد هسته‌ها می‌ماند، مشکل CPU است. اگر swap فعال شده یا در dmesg پیام OOM killer می‌بینی، مشکل رم است. ستون‌های si و so در خروجی vmstat سریع‌ترین راه تشخیص هستند.

آیا vCPU با هستهٔ فیزیکی برابر است؟

نه. vCPU یک سهمیهٔ پردازشی از هستهٔ فیزیکی است که بین چند ماشین مجازی تقسیم می‌شود. اگر مقدار steal time در top بالای ۵ درصد باشد، یعنی ماشین‌های دیگر روی همان هسته فشار می‌آورند و تو کمتر از سهمیه‌ات می‌گیری. این عدد را در ساعات پیک چک کن، نه در ساعت خلوت.

چه زمانی باید از یک سرور بزرگ به چند سرور کوچک مهاجرت کنم؟

وقتی به سقف پلن‌های موجود رسیدی، یا وقتی نمی‌توانی قطعی ناشی از تغییر پلن را بپذیری. در آن نقطه، جدا کردن دیتابیس از وب‌سرور اولین قدم است و بعد از آن می‌توانی لایهٔ وب را افقی بزرگ کنی. تا قبل از این نقطه، بزرگ‌تر کردن همان سرور ساده‌ترین و کم‌دردسرترین راه است.

قبل از خرید پلن بعدی، یک هفته داده جمع کن. اگر بعد از آن هنوز مطمئن نیستی کدام منبع گلوگاه است، احتمالاً مشکل در کد یا پیکربندی است، نه در اندازهٔ سرور.