بنچمارک سرور مجازی؛ روش سنجش CPU، دیسک و انتخاب دقیق پلن

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

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

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

• پردازنده: سرعت اجرای یک رشته کاری و توان انجام چند کار هم‌زمان را نشان می‌دهد. امتیاز تک‌هسته و چندهسته را جداگانه ثبت کنید.
• دیسک: تعداد عملیات ورودی و خروجی در ثانیه، پهنای باند و زمان پاسخ عملیات را مشخص می‌کند.
• شبکه: پهنای باند و تأخیر مسیر تا مقصد آزمایش را می‌سنجد؛ نتیجه آن به محل سرور مقصد و مسیر ارتباطی وابسته است.

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

معیارهای مهم در مقایسه عملکرد سرور

امتیاز تک‌هسته و چندهسته پردازنده

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

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

IOPS، پهنای باند و تأخیر دیسک

دیسک فقط با سرعت انتقال فایل بزرگ سنجیده نمی‌شود. دیتابیس معمولاً تعداد زیادی عملیات کوچک و پراکنده انجام می‌دهد؛ بنابراین IOPS و زمان تکمیل هر عملیات اهمیت بالایی دارند. در مقابل، کپی فایل پشتیبان یا جابه‌جایی آرشیو بیشتر به پهنای باند خواندن و نوشتن متوالی وابسته است.

تأخیر میانگین تصویر کلی می‌دهد، اما ممکن است مکث‌های طولانی را پنهان کند. صدک ۹۹ نشان می‌دهد یک درصد از عملیات کندتر از چه زمانی انجام شده‌اند. برای برنامه‌ای که به پاسخ سریع و یکنواخت نیاز دارد، این شاخص می‌تواند از میانگین مهم‌تر باشد.

پهنای باند و تأخیر شبکه

نتیجه تست شبکه فقط درباره مسیر میان سرور شما و مقصد آزمایش است. اگر مقصد در داخل کشور باشد، عدد به مسیر داخلی مربوط است و نمی‌توان آن را به دسترسی کاربران خارج از کشور تعمیم داد. در گزارش شبکه، مقصد، زمان تست، تعداد نمونه‌ها و نوع اتصال را ثبت کنید تا مقایسه منصفانه بماند.

اجرای بنچمارک پردازنده و ابزارهای عمومی

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

در زمان اجرای آزمون، سرویس‌های غیرضروری را متوقف کنید؛ اما اگر سرور از قبل بار واقعی دارد، آزمون سنگین را روی همان ماشین اجرا نکنید. بنچمارک CPU و دیسک می‌تواند منابع را برای چند دقیقه اشغال کند و پاسخ‌دهی سایت یا پایگاه داده را مختل سازد. بهتر است از یک سرور آزمایشی با شرایط مشابه استفاده کنید.

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

آزمون دیسک با fio؛ تنظیمات را ثابت نگه دارید

fio ابزار انعطاف‌پذیری برای ساخت بار کاری دیسک است. می‌توانید اندازه بلوک، نسبت خواندن به نوشتن، تعداد رشته‌ها، عمق صف و موتور ورودی و خروجی را مشخص کنید. همین آزادی باعث می‌شود دو اجرای ظاهراً مشابه، در صورت تفاوت تنظیمات، نتایج کاملاً متفاوتی داشته باشند.

برای مقایسه، دست‌کم دو سناریو را جدا در نظر بگیرید: عملیات کوچک تصادفی با بلوک 4k برای نزدیک شدن به الگوی بعضی بارهای دیتابیس، و عملیات متوالی با بلوک 1m برای بررسی انتقال فایل‌های بزرگ مانند بکاپ. این دو آزمون جایگزین یکدیگر نیستند و نباید نتیجه یکی را معیار دیگری قرار دهید.

پارامترهایی که نتیجه fio را تغییر می‌دهند

• bs: اندازه بلوک هر عملیات را تعیین می‌کند. تغییر آن، نوع بار کاری را عوض می‌کند.
• rw: الگوی خواندن و نوشتن را مشخص می‌کند؛ خواندن تصادفی با نوشتن متوالی قابل مقایسه نیست.
• iodepth: تعداد درخواست‌های در صف را کنترل می‌کند. مقدار تنظیم‌شده همیشه به معنای عمق صف واقعی نیست.
• numjobs: تعداد کارهای موازی را مشخص می‌کند و می‌تواند فشار بیشتری به دیسک وارد کند.
• ioengine: موتور ورودی و خروجی انتخابی روی امکان استفاده از عمق صف اثر می‌گذارد.
• direct: دسترسی مستقیم را برای کاهش اثر کش سیستم‌عامل فعال می‌کند.

اگر iodepth را روی ۳۲ قرار دهید اما موتور انتخابی نتواند درخواست‌ها را به شکل ناهمگام ارسال کند، عمق صف مؤثر ممکن است بسیار کمتر از مقدار مورد انتظار باشد. بنابراین در گزارش، فقط عدد iodepth را ننویسید؛ موتور I/O و خروجی واقعی ابزار را هم نگه دارید.

آزمون را روی یک فایل آزمایشی اجرا کنید، نه روی نام دستگاه یا پارتیشن. فایل باید از حافظه RAM بزرگ‌تر باشد تا نتیجه صرفاً سرعت کش حافظه را نشان ندهد. پیش از اجرا فضای آزاد دیسک را بررسی کنید و پس از پایان، فقط همان فایل آزمایشی را حذف کنید. تست نوشتن سنگین روی دیسک حاوی داده مهم، بدون پشتیبان‌گیری انجام نشود.

سه عددی که باید از خروجی fio بردارید

برای بار 4k، IOPS و تأخیر تکمیل عملیات را ثبت کنید. صدک ۹۹ را کنار میانگین بنویسید تا مکث‌های غیرمعمول دیده شوند. برای بار 1m، پهنای باند خواندن یا نوشتن را نگه دارید؛ این عدد برای تخمین زمان جابه‌جایی فایل بزرگ کاربردی‌تر است.

هر نتیجه باید همراه با نوع عملیات، اندازه فایل، تعداد jobها، عمق صف، موتور I/O و مدت آزمون ذخیره شود. بدون این اطلاعات، عدد به‌تنهایی قابل بازتولید نیست و ممکن است مقایسه دو سرور گمراه‌کننده شود.

کدام معیار برای سایت، دیتابیس و پردازش سنگین مهم‌تر است؟

برای سایت وردپرسی یا برنامه‌ای با درخواست‌های کوتاه، سرعت تک‌هسته و تأخیر عملیات دیسک می‌تواند نقش پررنگی داشته باشد. برای دیتابیس، رفتار I/O تصادفی و صدک ۹۹ اهمیت پیدا می‌کند. در کامپایل و پردازش موازی، امتیاز چندهسته مهم‌تر می‌شود و برای بکاپ یا فایل‌سرور باید پهنای باند انتقال فایل را جدی گرفت.

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

خطاهای رایج در مقایسه دو سرور

• مقایسه امتیازهای نسخه‌های متفاوت Geekbench بدون توجه به نسخه آزمون.
• اجرای تست دیسک بدون direct و نتیجه‌گیری بر اساس عددی که کش سیستم‌عامل آن را بالا برده است.
• اعتماد به یک اجرای منفرد و نادیده گرفتن نوسان بار میزبان.
• مقایسه خروجی خود با اعدادی که با فایل، عمق صف، سیستم فایل یا نسخه ابزار دیگری تولید شده‌اند.
• اجرای آزمون سنگین روی سرور عملیاتی و ایجاد اختلال برای کاربران.
• ثبت نکردن درصد CPU Steal و نسبت دادن تمام افت عملکرد به مدل پردازنده.

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

روش ثبت نتیجه برای مقایسه منصفانه

1. سیستم‌عامل، نسخه کرنل، معماری و نسخه ابزارها را ثبت کنید.
2. در صورت امکان آزمون را روی سروری تمیز یا محیط آزمایشی مشابه اجرا کنید.
3. پیش از شروع، بار پردازنده و مقدار steal را بررسی کنید.
4. YABS را با تنظیم یکسان اجرا و خروجی را ذخیره کنید؛ اگر شبکه موضوع مقایسه نیست، آزمون شبکه را جدا نگه دارید.
5. دو سناریوی fio را با پارامترهای ثابت اجرا و IOPS، تأخیر صدک ۹۹ و پهنای باند را یادداشت کنید.
6. آزمون را در چند بازه زمانی، از جمله ساعت اوج و ساعت خلوت، تکرار کنید.
7. کمینه، بیشینه و میانه را کنار هم نگه دارید؛ فقط بهترین عدد را معیار انتخاب قرار ندهید.

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

پرسش‌های متداول درباره بنچمارک سرور مجازی

آیا اجرای YABS به سرور آسیب می‌زند؟

اجرای آزمون به‌خودی‌خود به معنی تغییر دائمی سیستم‌عامل نیست، اما تست CPU و دیسک می‌تواند منابع را اشغال کند. روی سرور پرترافیک، این فشار ممکن است پاسخ‌دهی سرویس را کاهش دهد؛ آزمون را در محیط جدا یا زمان کم‌بار اجرا کنید.

چه امتیازی برای Geekbench خوب محسوب می‌شود؟

یک عدد ثابت برای همه کاربردها وجود ندارد. نسخه آزمون و نوع پردازنده را مشخص کنید و دو گزینه موردنظر را با نسخه یکسان بسنجید. سپس امتیاز را با بار واقعی برنامه خود تطبیق دهید.

چرا دو اجرای پیاپی نتیجه یکسان ندارند؟

بار میزبان، فعالیت ماشین‌های مجازی دیگر، فرایندهای پس‌زمینه و وضعیت ذخیره‌ساز ثابت نیست. چند بار تست کنید و درصد steal را کنار نتیجه CPU ثبت کنید تا نوسان قابل بررسی باشد.

برای دیتابیس IOPS مهم‌تر است یا تأخیر؟

هر دو مهم‌اند، اما تأخیر صدک ۹۹ نشان می‌دهد عملیات کند در چه زمانی تمام می‌شود. IOPS ظرفیت انجام تعداد عملیات را نشان می‌دهد. برای تصمیم بهتر، این دو شاخص را با الگوی واقعی خواندن و نوشتن دیتابیس مقایسه کنید.

آیا خروجی سرورهای دیگر را می‌توان معیار قرار داد؟

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

چطور گلوگاه پردازنده را از دیسک تشخیص بدهم؟

در زمان بار واقعی، مصرف CPU، ستون wa در vmstat و درصد steal را کنار هم ببینید. مصرف بالای پردازنده با wa پایین می‌تواند به بار محاسباتی اشاره کند؛ wa بالا به انتظار I/O مربوط است و steal بالا یعنی ماشین برای دریافت زمان CPU منتظر مانده است.

جمع‌بندی؛ بنچمارک را بر اساس نوع استفاده بخوانید

بنچمارک سرور زمانی تصمیم‌ساز می‌شود که به چند شاخص محدود اما مرتبط با کار شما تکیه کند. برای سایت، تک‌هسته؛ برای دیتابیس، IOPS و صدک ۹۹؛ برای پردازش موازی، چندهسته؛ و برای بکاپ، پهنای باند انتقال فایل را در اولویت بگذارید. نسخه ابزار و پارامترهای آزمون را ثابت نگه دارید، اثر کش را کنترل کنید، فایل آزمایشی بزرگ‌تر از RAM بسازید و مقدار CPU Steal را کنار هر نتیجه ثبت کنید. سه اجرای جدا در زمان‌های متفاوت، تصویر قابل‌اعتماد‌تری از یک عدد منفرد می‌سازد.

چطور نتایج بنچمارک را به تصمیم خرید تبدیل کنیم؟

پس از پایان آزمون‌ها، نتایج را در یک جدول برای هر سرور ثبت کنید. در کنار امتیازها، مشخصات محیط را هم بنویسید: نسخه سیستم‌عامل، نسخه ابزار، اندازه فایل آزمایشی، تنظیمات fio، زمان اجرا و وضعیت CPU Steal. این اطلاعات کمک می‌کند اگر چند روز بعد آزمون را تکرار کردید، بدانید تغییر نتیجه از سخت‌افزار بوده یا از تفاوت شرایط اجرا.

اگر یک گزینه در امتیاز تک‌هسته بهتر است اما در تأخیر دیسک ضعیف‌تر عمل می‌کند، انتخاب به اولویت نرم‌افزار شما وابسته خواهد بود. برای وب‌سایتی که درخواست‌های پردازشی کوتاه دارد، سرعت تک‌هسته مهم است؛ اما اگر دیتابیس دائماً عملیات کوچک انجام می‌دهد، مکث‌های دیسک می‌توانند تجربه کاربر را خراب کنند. برای سرور بکاپ نیز پهنای باند فایل بزرگ و پایداری نوشتن اهمیت بیشتری دارد.

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

چک‌لیست نهایی پیش از انتخاب

• آیا آزمون‌ها با نسخه یکسان ابزار روی هر دو سرور اجرا شده‌اند؟
• آیا نوع بار آزمایش با استفاده واقعی شما تناسب دارد؟
• آیا فایل تست از RAM بزرگ‌تر بوده و اثر کش کنترل شده است؟
• آیا پارامترهای fio، از جمله ioengine و iodepth، ثبت شده‌اند؟
• آیا CPU Steal و زمان اجرای تست کنار امتیاز CPU آمده‌اند؟
• آیا نتیجه در ساعت اوج و زمان خلوت تکرار شده است؟
• آیا آزمون روی سرور عملیاتی، سرویس کاربران را تحت تأثیر قرار نداده است؟

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