تست سرعت Hard های SSD

برای سنجش واقعی سرعت دیسک، خروجی یک دستور ساده مثل dd کافی نیست؛ باید سه چیز را جداگانه اندازه بگیرید: تعداد عملیات در ثانیه (IOPS)، توان عبوری (Throughput) و تاخیر پاسخ (Latency). ابزار استاندارد این کار fio است و نتیجه هر تست فقط به همان الگویی که تعریف کرده‌اید مربوط می‌شود.

در ادامه روش درست تست دیسک روی لینوکس را می‌بینید؛ روشی که هم روی سرور فیزیکی جواب می‌دهد و هم روی سرور مجازی.

چرا تست قدیمی با dd گمراه‌کننده است

سال‌ها این حلقه معروف دست‌به‌دست می‌شد: هزار بار خواندن یک بلوک ۴ کیلوبایتی از /dev/sda با dd و اندازه‌گیری زمان کل با time؛ ادعا این بود که اگر چند ثانیه طول بکشد یعنی SSD و اگر بیشتر شود یعنی دیسک مکانیکی. این معیار امروز دیگر معتبر نیست، به دلایل مشخص:

• در آن حلقه به ازای هر تکرار یک فرایند تازه dd ساخته می‌شود؛ بخش بزرگی از زمانی که اندازه می‌گیرید هزینه ساخت فرایند است، نه کار دیسک.
• بدون iflag=direct پاسخ‌ها از حافظه نهان صفحه (Page Cache) هسته برمی‌گردد و شما در عمل سرعت رم را می‌سنجید، نه دیسک را.
• عمق صف همیشه یک است. SSD و به‌ویژه NVMe وقتی توان واقعی‌شان را نشان می‌دهند که درخواست‌های هم‌زمان در صف باشد.
• متغیر $RANDOM در Bash بازه محدودی دارد، پس آدرس‌هایی که می‌خوانید آن‌قدرها هم تصادفی و پراکنده نیستند.
• دسته‌بندی امروزی فقط «SSD هست یا نیست» نیست؛ میان یک SSD معمولی SATA و یک دیسک NVMe هم تفاوت جدی وجود دارد و پاسخ «بله SSD است» چیزی درباره آن نمی‌گوید.

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

سه عددی که باید جدا اندازه بگیرید

IOPS

تعداد عملیات ورودی/خروجی در ثانیه، معمولا با بلوک کوچک (۴ کیلوبایت) و الگوی تصادفی. این عدد سرنوشت دیتابیس، میل سرور و سایت پویا را تعیین می‌کند.

Throughput

حجم داده جابه‌جاشده در ثانیه، معمولا با بلوک بزرگ (۱ مگابایت) و الگوی ترتیبی. این عدد برای بکاپ‌گیری، انتقال فایل و سرور دانلود اهمیت دارد.

Latency

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

رابطه این سه ساده است: IOPS ضرب در اندازه بلوک تقریبا همان Throughput می‌شود. یعنی نمی‌توانید هر سه را هم‌زمان بیشینه کنید و هر تست فقط یک گوشه از توان دیسک را نشان می‌دهد.

نصب fio

روی دبیان و اوبونتو: apt update && apt install -y fio

روی AlmaLinux، Rocky Linux و RHEL: dnf install -y fio. اگر بسته پیدا نشد، اول مخزن EPEL را فعال کنید با dnf install -y epel-release.

اگر هنوز روی CentOS 7 یا CentOS 8 هستید، هر دو به پایان چرخه پشتیبانی رسیده‌اند (CentOS 8 در پایان ۲۰۲۱ و CentOS 7 در میانه ۲۰۲۴)، دیگر وصله امنیتی نمی‌گیرند و مخازنشان جابه‌جا شده است. همین تست را بهانه کنید و مهاجرت به AlmaLinux یا Rocky Linux را در برنامه بگذارید.

یک هشدار پیش از اجرا

هرگز تست نوشتن را روی دستگاه خام اجرا نکنید. اگر مقدار --filename را روی چیزی مثل /dev/sda بگذارید و الگو از نوع نوشتن باشد، fio بدون پرسش روی پارتیشن‌ها می‌نویسد و داده‌ها از بین می‌رود. همیشه یک فایل موقت داخل فایل‌سیستم بسازید، مثل /var/tmp/fiotest.

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

تست‌های پایه با fio

خواندن تصادفی با عمق صف بالا: fio --name=randread --filename=/var/tmp/fiotest --size=4G --bs=4k --rw=randread --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 --runtime=60 --time_based --group_reporting

نوشتن تصادفی: همان دستور با --rw=randwrite و نامی متفاوت در --name.

خواندن و نوشتن ترتیبی: همان دستور با --bs=1M --iodepth=8 و به‌ترتیب --rw=read یا --rw=write.

سنجش تاخیر خالص: همان دستور با --bs=4k --rw=randread --iodepth=1. عمق صف یک، کف تاخیر دیسک را نشان می‌دهد.

در پایان فایل موقت را پاک کنید: rm -f /var/tmp/fiotest

دو نکته حیاتی: بدون --direct=1 نتیجه شما سرعت حافظه نهان است نه دیسک؛ و مقدار --size باید به‌قدر کافی بزرگ باشد که کش‌ها نتوانند کل داده را نگه دارند. اگر موتور libaio در دسترس نبود، از --ioengine=psync استفاده کنید و بدانید در آن حالت عمق صف موثر پایین می‌ماند. روی هسته‌های جدید لینوکس موتور --ioengine=io_uring هم در دسترس است؛ فقط برای مقایسه، همه اجراها را با یک موتور بگیرید.

خروجی fio را چطور بخوانیم

در گزارش پایانی دنبال سه بخش بگردید: مقدار IOPS=، مقدار BW= برای توان عبوری، و جدول clat percentiles برای تاخیر. در جدول درصدها، ردیف‌های 95.00th و 99.00th را ببینید نه فقط avg را. اگر فاصله میانگین با صدک ۹۹ زیاد باشد، دیسک ناپایدار است حتی اگر عدد IOPS خوب به نظر برسد.

روی سرور مجازی نتیجه ثابت نیست

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

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

نکته دیگر اینکه فایل /sys/block/sda/queue/rotational روی سرور مجازی قابل اتکا نیست؛ دیسک مجازی معمولا صفر گزارش می‌کند، حتی وقتی پشت آن آرایه‌ای از دیسک مکانیکی باشد. تنها راه فهمیدن رفتار واقعی، همان تست بار است.

نتیجه را برای کدام بار تفسیر می‌کنید

عدد خوب و بد مطلق وجود ندارد؛ همه چیز به الگوی کاری شما بستگی دارد:

• دیتابیس: InnoDB در MySQL با صفحه ۱۶ کیلوبایتی و PostgreSQL با صفحه ۸ کیلوبایتی کار می‌کند و هر دو برای تایید تراکنش به fsync متکی هستند. پس تست معنادار برای شما نوشتن تصادفی با بلوک کوچک و تاخیر پایین است، نه مگابایت بر ثانیه. برای شبیه‌سازی نزدیک‌تر، گزینه --fsync=1 را به دستور نوشتن اضافه کنید و ببینید IOPS چقدر افت می‌کند.
• فایل‌سرور و سرور دانلود: اینجا خواندن ترتیبی و پهنای باند شبکه تعیین‌کننده است. اگر Throughput دیسک از ظرفیت پورت شبکه بیشتر است، ارتقای دیسک هیچ تغییری در تجربه کاربر ایجاد نمی‌کند.
• وب‌سرور معمولی: بیشتر خواندن‌ها از کش رم پاسخ می‌گیرد؛ تاخیر نوشتن لاگ و کش مهم‌تر از IOPS اوج است.

اشتباه‌های رایج

• جا انداختن --direct=1 و گزارش سرعت رم به‌جای دیسک.
• انتخاب --size کوچک‌تر از حجم رم سرور.
• یک بار اجرا کردن تست و تصمیم گرفتن بر اساس همان یک عدد.
• اجرای تست سنگین روی سرور فعال؛ خود fio سرویس‌های در حال اجرا را کند می‌کند.
• مقایسه خروجی fio با عددی که ابزار دیگری گرفته است. مقایسه فقط با پارامترهای یکسان معنا دارد.
• تست روی دیسکی که تقریبا پر شده؛ فضای خالی کم روی SSD عملکرد نوشتن را پایین می‌آورد.

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